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1  Introduction 


Reasoning  about  algorithms  for  asynchronous  concurrent  systems  is  difficult,  primarily  because  of 
the  arbitrary  interleaving  of  process  steps  that  may  occur  in  an  execution.  As  a  result,  researchers 
have  turned  to  formal  models  in  order  to  define  problems  precisely,  give  unambiguous  descriptions 
of  algorithms,  and  construct  careful  proofs  for  safety  and  progress  properties.  These  models  allow 
one  to  be  explicit  about  the  possible  interleavings  that  may  occur  in  a  distributed  system  and  may 
specify  which  of  those  interleavings  are  to  be  considered  “fair”  to  the  individual  system  components. 
Examples  include  CSP  [4],  in  which  system  components  communicate  by  sending  messages  over 
synchronous  channels,  and  UNITY  [1],  in  which  components  communicate  by  reading  and  modifying 
shared  variables. 

The  I/O  automaton  model  [7,  8]  is  particularly  well-suited  for  modelling  distributed  algorithms 
described  using  message  passing.  The  I/O  automaton  model  is  a  (not  necessarily  finite)  state 
machine  model  that  provides  extra  support  for  classifying  actions  as  input  or  output  and  for  de¬ 
scribing  fairness  conditions.  Precise  problem  statements  are  defined  in  terms  of  the  input  and 
output  actions  that  occur  at  the  boundary  between  the  algorithm  and  its  “environment.”  These 
problem  statements  may  include  nontrivial  liveness  constraints  on  the  behavior  of  the  algorithm. 
Careful,  algorithm  descriptions  are  constructed  by  specifying  the  states  and  transition  relations  of 
I/O  automata.  A  range  of  proof  techniques,  from  simple  assertional  reasoning  to  hierarchical  pos¬ 
sibilities  mappings,  may  be  used  to  verify  an  algorithm  satisfies  a  problem  statement.  In  addition, 
the  model  can  be  used  for  carrying  out  complexity  analysis  and  for  proving  impossibility  results. 
The  communication  mechanism  in  a  distributed  system  is  modeled  as  an  explicit  I/O  automaton 
that  shares  actions  with  the  other  system  components.  Therefore,  the  model  can  accommodate  a 
variety  of  message-passing  systems,  from  systems  with  strictly  FIFO  message  delivery  to  those  in 
which  messages  may  be  delivered  out  of  order  or  not  at  all. 

Although  the  I/O  automaton  model  provides  excellent  support  for  modelling  message-passing 
algorithms,  many  of  the  important  asynchronous  concurrent  algorithms  are  described  using  shared 
memory.  And  in  some  cases  one  might  wish  to  use  both  shared-memory  and  message-passing  to 
describe  different  parts  of  an  algorithm.  Therefore,  it  would  appear  that  introducing  a  shared- 
memory  mechanism  into  the  I/O  automaton  model  would  be  a  useful  unification  of  these  two 
approaches.  The  shared  memory  model  of  Lynch  and  Fischer  [5]  introduced  the  separation  of  input 
and  output  actions,  and  was  a  precursor  of  the  current  I/O  automaton  model.  However,  until  now 
it  has  not  been  clear  how  to  integrate  the  two  basic  approaches. 

In  this  paper,  we  extend  the  1/ 0  automaton  model  to  allow  modelling  of  shared  memory  systems, 
as  well  as  systems  that  have  both  shared  memory  and  shared  action  communication.  A  full  range 
of  types  of  atomic  accesses  to  shared  memory  is  allowed,  from  basic  reads  and  writes  to  atomic 
read-mod  iy- write.  We  define  a  special  class  of  actions,  called  “shared  memory  actions,”  to  model 
atomic  accesses  to  shared  memory.  Each  shared  memory  action  contains  ex«.ra  information  that 
corresponds  to  the  contents  of  the  shared  memory  before  and  after  the  action  occurs.  A  “shared 
memory  automaton”  is  then  defined  to  be  an  I/O  automaton  that  satisfies  certain  natural  conditions 
regarding  its  shared  memory  actions.  For  example,  one  condition  captures  the  idea  that  an  access 
to  shared  memory  must  be  prepared  to  observe  any  value  in  the  memory. 

Since  shared  memory  automata  are  simply  special  cases  of  I/O  automata,  all  the  I/O  automa¬ 
ton  model  definitions  and  properties  (notably  composition  and  fairness)  apply  to  shared  memory 
automata  as  well.  We  show  that  composing  of  a  collection  of  shared  memory  automata  (for  a  given 
set  of  shared  variables)  yields  another  shared  memory  automaton  (for  the  same  set  of  variables). 
To  combine  shared  memory  automata  having  different  (not  necessarily  disjoint)  sets  of  shared  vari¬ 
ables,  we  define  an  “augmentation”  operator  that  is  used  to  expand  the  set  of  shared  variables 
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for  each  component  before  composing.  We  show  that  the  natural  compositionality  results  hold 
when  we  combine  shared  memory  automata  in  this  way.  For  example,  projecting  the  execution 
of  a  composition  on  the  individual  components  yields  executions  of  those  components.  Since  we 
expose  the  observed  state  of  shared  memory  in  the  behavior  of  an  automaton,  we  also  achieve 
compositionality  of  the  behaviors  of  shared  memory  automata.  That  is,  in  the  standard  sense  of 
I/O  automaton  composition,  the  behaviors  of  a  composition  of  shared  memory  automata  are  the 
same  as  the  composition  of  the  behaviors  of  the  individual  automata. 

Shared  memory  automata  operate  in  a  system  in  which  the  environment  is  free  to  change  the 
contents  of  the  shared  memory  at  any  time.  We  define  a  “closeout”  operator,  which  takes  a  shared 
memory  automaton  and  a  set  of  variables  and  produces  a  new  shared  memory  automaton  in  which 
the  given  set  of  variables  is  made  private,  absorbed  into  the  local  state.  In  this  way,  we  restrict 
the  set  of  components  in  a  system  that  may  access  portions  of  the  shared  memory.1  We  provide  an 
analogous  closeout  operator  on  sets  of  behaviors,  and  we  show  that  the  behaviors  of  a  closed  out 
automaton  are  the  same  as  the  clc:ed  out  behaviors  of  the  original  automaton. 

Just  as  does  the  original  I/O  automaton  model,  our  extended  model  supports  careful  prob¬ 
lem  specification  (including  both  safety  and  progress  properties),  unambiguous  system  description, 
verification  and  analysis.  Both  safety  and  progress  properties  of  algorithms  may  be  shown  using 
standard  proof  techniques  (e.g.,  invariant  assertions  and  variant  functions).  To  illustrate  these  tech¬ 
niques,  we  present  and  prove  the  correctness  of  Dijkstra’s  classical  shared  memory  mutual  exclusion 
algorithm  using  the  shared  memory  I/O  automaton  model. 

The  first  author  is  currently  developing  the  Spectrum  Simulation  System,  a  research  tool  for 
the  design  of  distributed  algorithms  [3].  Spectrum  consists  of  a  language  and  simulator  based  on 
the  I/O  automaton  model.  Users  express  distributed  algorithms  as  I/O  automata  and  simulate 
them  directly,  using  the  semantics  of  the  formal  model.  A  graphical  interface  is  provided  for  con¬ 
structing  systems  of  automata  and  animating  their  executions.  Using  I/O  automaton  composition, 
Spectrum  users  may  define  composed  types  hierarchically,  study  simulations  at  varying  levels  of 
detail,  and  create  specialized  debugging  and  analysis  devices.  Incorporating  the  shared  memory 
extensions  (specifically,  the  closeout  operator)  into  this  system  will  allow  simulation  of  message- 
passing  algorithms,  shared  memory  algorithms,  and  hybrid  algorithms  all  within  a  single  formal 
framework.  This  is  an  added  benefit  of  building  a  powerful  unified  model  that  accommodates  both 
message-passing  and  shared  memory  communication.  Although  Spectrum  does  not  yet  support  the 
closeout  operator,  we  were  able  to  use  Spectrum  to  simulate  the  example  algorithm  presented  in 
Section  4  by  explicitly  constructing  the  closed  out  automaton.  The  invariants  and  variant  function 
were  mechanically  checked  for  random  executions  of  the  algorithm. 

The  remainder  of  the  paper  is  organized  as  follows.  In  Section  2,  we  review  the  I/O  automaton 
model.  We  define  our  extensions  for  shared  memory  in  Section  3  and  show  some  important  prop¬ 
erties  that  follow  from  these  definitions.  In  Section  4,  the  extended  model  is  used  to  present  and 
prove  correct  Dijkstra’s  shared  memory  mutual  exclusion  algorithm.  The  paper  concludes  with  a 
summary  and  discussion. 

2  The  I/O  Automaton  Model 

The  following  introduction  to  the  I/O  automaton  model  is  adapted  from  [8],  which  explains  the 
model  in  more  detail,  presents  examples,  and  includes  comparisons  to  other  models. 

‘The  ability  to  closeout  with  respect  to  a  subset  of  the  shared  variables  (as  opposed  to  the  entire  set)  may  be 
likened  to  lexical  scoping  of  variable  declarations  in  a  conventional  programming  language. 
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2.1  I/O  Automata 

I/O  automata  are  best  suited  for  modelling  systems  in  which  the  components  operate  asyn¬ 
chronously.  Each  system  component  is  modeled  as  an  I/O  automaton,  which  is  essentially  a 
nondeterministic  (possibly  infinite  state)  automaton  with  an  action  labeling  each  transition.  An 
automaton’s  actions  are  classified  as  either  ‘input’,  ‘output’,  or  ‘internal’.  An  automaton  can  es¬ 
tablish  restrictions  on  when  it  will  perform  an  output  or  internal  action,  but  it  is  unable  to  block 
the  performance  of  an  input  action.  An  automaton  is  said  to  be  closed  if  it  has  no  input  actions; 
it  models  a  closed  system  that  does  not  interact  with  its  environment. 

Formally,  an  action  signature  S’  is  a  partition  of  a  set  acts(S)  of  actions  into  three  disjoint 
sets  in{S),  out(S),  and  int(S)  of  input  actions,  output  actions,  and  internal  actions,  respectively. 
We  denote  by  ext(S)  =  in(S )  U  out(S)  the  set  of  external  actions.  We  denote  by  local(S)  = 
out(S)Uint(S)  the  set  of  locally-controlled  actions.  An  I/O  automaton  consists  of  five  components: 

•  an  action  signature  sig(A), 

•  a  set  states  (A)  of  states, 

'  a  nonempty  set  start(A)  C  states(A)  of  start  states, 

•  a  transition  relation  steps(A)  C  states(A)  x  acts(A)  x  states(A)  with  the  property  that  for 
every  state  s1  and  input  action  tt  there  is  a  transition  (s',ir,s)  in  steps  (A),  and 

•  an  equivalence  relation  part(A)  partitioning  the  set  local(A)  into  at  most  a  countable  number 
of  equivalence  classes. 

The  equivalence  relation  part(A)  will  be  used  in  the  definition  of  fair  computation.  Each  class  of 
the  partition  may  be  thought  of  as  a  separate  process.  We  refer  to  an  element  (s',7r,  s)  of  steps(A) 
as  a  step  of  A.  Ji  ( /.  /r ,  s)  is  a  step  of  A,  then  7r  is  said  to  be  enabled  in  s'.  Since  every  input  action 
is  enabled  in  every  state,  automata  are  said  to  be  input-enabled.  This  means  that  the  automaton 
is  unable  to  block  its  input. 

An  execution  of  A  is  a  finite  sequence  so>  $i>  •  •  • ,  or  an  infinite  sequence  «0)  si,  tt2,  . . . 
of  alternating  states  and  actions  of  A  such  that  (st-,7r,-+i,s,-+i)  is  a  step  of  A  for  every  i  and 
So  €  start(A).  The  schedule  of  an  execution  a  is  the  subsequence  of  a  consisting  of  the  actions 
appearing  in  a.  The  behavior  of  an  execution  or  schedule  a  of  A  is  the  subsequence  of  a  consisting  of 
external  actions.  The  sets  of  executions,  finite  executions,  scneduies,  finite  schedules,  behaviors,  and 
finite  behaviors  are  denoted  execs(A),finexecs(A),  scheds{A),finscheds{A),  behs(A),  and  finbehs(A), 
respectively.  The  same  action  may  occur  several  times  in  an  execution  or  a  schedule;  we  refer  to  a 
particular  occurrence  of  an  action  as  an  event. 

The  separation  of  input  and  output  actions  will  be  important  in  our  shared  memory  extensions 
for  two  reasons.  First,  the  fact  that  each  action  is  under  the  control  of  exactly  one  component 
means  that  by  simply  using  actions  to  model  updates  to  the  shared  memory,  we  capture  the  notion 
of  a  single  module  making  an  atomic  update  to  shared  memory  (without  any  active  participation 
by  other  modules).  Second,  the  fact  that  input  actions  are  always  enabled  means  that  we  can 
use  shared  memory  input  actions  to  construct  modules  that  passively  observe  the  shared  memory 
accesses  by  others  without  interfering.  We  will  return  to  these  points  in  Sect  on  3.7. 

2.2  Composition 

We  can  construct  an  automaton  modelling  a  complex  system  by  composing  automata  modelling 
the  simpler  system  components.  When  we  compose  a  collection  of  automata,  we  identify  an  output 
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action  it  of  one  automaton  with  the  input  action  it  of  each  automaton  having  it  as  an  input  action. 
Consequently,  when  one  automaton  having  it  as  an  output  action  performs  it  ,  all  automata  having 
it  as  an  action  perform  it  simultaneously  (automata  not  having  it  as  an  action  do  nothing). 

Since  we  require  that  most  one  system  component  controls  the  performance  of  any  given  action, 
we  must  place  some  compatibility  restrictions  on  the  collections  of  automata  that  may  be  composed. 

A  countable  collection  {Sf},^/  of  action  signatures  is  said  to  be  strongly  compatible  if  for  all  i,j  £  I 
satisfying  j  we  have 

1.  out(Si)  fl  out(Sj)  =  0, 

2.  int(Si)  n  acts(Sj)  —  0,  and 

3.  no  action  is  contained  in  infinitely  many  sets  acts(Si). 

We  say  that  a  collection  of  automata  are  strongly  compatible  if  their  action  signatures  are  strongly 
compatible. 

The  composition  S  =  Hfe/  §i  °f  a  countable  collection  of  strongly  compatible  action  signatures 
{SiJ-j-gj  is  defined  to  be  the  action  signature  with 

•  in(S)  =  U ieiin(Si)  -  U ieiout(Si), 

•  out(S)  =  U iziout(Si),  and 

•  int(S)  =  U  ieiint(Si). 

The  composition  A  =  n»g/  A{  of  a  countable  collection  of  strongly  compatible  automata  {A,}t-e/  is 
the  automaton  defined  as  follows:2 

•  sig(A)  =  Fife/  sio(A0> 

•  states(A)  =  Yli£j  states(Ai), 

•  start(A)  =  Ylielstart(Ai), 

•  steps(A)  is  the  set  of  triples  (si,  7r,  &)  such  that,  for  alii  £  J,  if  it  £  acts{Ai)  then  (sl[i],  it,  s*2[i])  £ 
steps(Ai),  and  if  it  £  acts(Ai)  then  sl[i]  =  sl[i],  and 

•  part(A)  =  Uieipart(Ai). 

Given  an  execution  a  =  ...  of  A,  let  a\A ,■  (read  “a  projected  on  A,-”)  be  the  sequence 

obtained  by  deleting  itjSj  when  itj  £  acts(Ai)  and  replacing  the  remaining  sj  by  s}[i]. 

In  defining  the  behaviors  of  a  composition,  it  is  sometimes  convenient  to  hide  actions,  making 
them  internal  actions  of  the  composition.  The  hidden  actions  are  usually  locally  controlled  actions 
of  the  composition  that  are  also  inputs  to  some  of  its  own  components. 

2 Here  jfarf(A)  and  states(A)  are  defined  in  terms  of  the  ordinary  Cartesian  product,  while  sig(A)  is  defined  in 
terms  of  the  composition  of  actions  signatures  just  defined.  Also,  we  use  the  notation  Sf«]  to  denote  the  »th  component 
of  the  state  vector  s. 
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2.3  Fairness 


Of  all  the  executions  of  an  I/O  automaton,  we  are  primarily  interested  in  the  ‘fair’  executions  — 
those  that  permit  each  of  the  automaton’s  primitive  components  (i.e.,  its  classes  or  processes)  to 
have  infinitely  many  chances  to  perform  output  or  internal  actions.  The  definition  of  automaton 
composition  says  that  an  equivalence  class  of  a  component  automaton  becomes  an  equivalence 
class  of  a  composition,  and  hence  that  composition  retains  the  essential  structure  of  the  system’s 
primitive  components.  In  the  model,  therefore,  being  fair  to  each  component  means  being  fair  to 
each  equivalence  class  of  locally-controlled  actions.  A  fair  execution  of  an  automaton  A  is  defined 
to  be  an  execution  a  of  A  such  that  the  following  conditions  hold  for  each  class  C  of  part(A): 

1.  If  a  is  finite,  then  no  action  of  C  is  enabled  in  the  final  state  of  a. 

2.  If  a  is  infinite,  then  either  a  contains  infinitely  many  events  from  C,  or  a  contains  infinitely 
many  occurrences  of  states  in  which  no  action  of  C  is  enabled. 

We  denote  the  set  of  fair  executions  of  A  by  fairexecs(A).  We  say  that  /?  is  a  fair  behavior  of  A  if  /J 
is  the  behavior  of  a  fair  execution  of  A,  and  we  denote  the  set  of  fair  behaviors  of  A  by  fairbchs(A). 
Similarly,  /?  is  a  fair  schedule  of  A  if  /?  is  the  schedule  of  a  fair  execution  of  A,  and  we  denote  the 
set  of  fair  schedules  of  A  by  fairscheds(A). 

In  our  example  progress  proof  of  Dijkstra’s  mutual  exclusion  algorithm,  we  will  rely  on  the 
built-in  fairness  feature  of  the  I/O  automaton  model  in  order  to  reason  about  progress  in  a  system 
containing  several  active,  non-failing  processes  accessing  passive  shared  memory. 

2.4  Problem  Specification 

A  ‘problem’  to  be  solved  by  an  I/O  automaton  is  formalized  as  a  set  of  (finite  and  infinite)  sequences 
of  external  actions.  An  automaton  is  said  to  solve  a  problem  P  provided  that  its  set  of  fair  behaviors 
is  a  subset  of  P.  Although  the  model  does  not  allow  an  automaton  to  block  its  environment  or 
eliminate  undesirable  inputs,  we  can  formulate  our  problems  (i.e.,  correctness  conditions)  to  require 
that  an  automaton  exhibits  some  behavior  only  when  the  environment  observes  certain  restrictions 
on  the  production  of  inputs. 

We  want  a  problem  specification  to  be  an  interface  together  with  a  set  of  behaviors.  We  therefore 
define  a  schedule  module  U  to  consist  of  two  components,  an  action  signature  sig(H),  and  a  set 
scheds(H)  of  schedules.  Each  schedule  in  scheds(H)  is  a  finite  or  infinite  sequence  of  actions  of  H . 
Subject  to  the  same  restrictions  as  automata,  schedule  modules  may  be  composed  to  form  other 
schedule  modules.  The  resulting  signature  is  defined  as  for  automata,  and  the  schedules  scheds(H) 
is  the  set  of  sequences  ft  of  actions  of  H  such  that  for  every  module  II'  in  the  composition,  (S\IV  is 
a  schedule  of  if'. 

It  is  often  the  case  that  an  automaton  behaves  correctly  only  in  the  context  of  certain  restrictions 
on  its  input.  A  useful  notion  for  discussing  such  restrictions  is  that  of  a  module  ‘preserving’  a 
property  of  behaviors.  A  set  of  sequences  V  is  said  to  be  prefix-closed  if  ft  £  V  whenever  both  /? 
is  a  prefix  of  a  and  a  £  V.  A  module  M  (either  an  automaton  or  schedule  module)  is  said  to  be 
prefix-closed  provided  that  finbehs(M)  is  prefix-closed.  Let  M  be  a  prefix-closed  module  and  let  V 
be  a  nonempty,  prefix-closed  set  of  sequences  of  actions  from  a  set  $  satisfying  $  fl  int(M)  =  0. 
We  say  that  h.  preserves  V  if  £  V  whenever  (3\ $  £  V,  n  £  out(M),  and  (3w\M  £  finbehs(M). 
Informally,  a  module  preserves  a  property  V  iff  the  module  is  not  the  first  to  violate  V:  as  long 
as  the  environment  only  provides  inputs  such  that  the  cumulative  behavior  satisfies  V,  the  module 
will  only  perform  outputs  such  that  the  cumulative  behavior  satisfies  V.  One  can  prove  that  a 
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composition  preserves  a  property  by  showing  that  each  of  the  component  automata  preserves  the 
property. 

3  Shared  Memory  Definitions 

In  this  section,  we  present  a  set  of  definitions  that  extends  the  I/O  automaton  model  in  order  to 
allow  modelling  shared  memory  algorithms.  We  do  not  redefine  any  concepts,  but  simply  add  new 
concepts  to  the  existing  model.  We  model  each  system  component  that  accesses  shared  memory  as 
a  restricted  I/O  automaton  called  a  “shared  memory  automaton”.  The  fact  that  shared  memory 
automata  are  simply  special  cases  of  I/O  automata  means  that  all  the  standard  definitions  and 
properties  of  I/O  automata  (e.g.,  composition  and  fairness)  can  be  used  directly  in  descriptions 
and  proofs  of  shared  memory  algorithms. 

3.1  Variables 

We  will  model  shared  memory  in  terms  of  a  collection  of  variables,  so  the  first  step  is  to  define 
what  is  meant  by  a  variable.  We  define  a  variable  x  to  have  a  domain  dom(x)  of  values  and  an 
initial  value  init(x)  €  dom(z).  Given  a  set  A  of  variables,  we  model  a  state  of  X  by  an  assignment 
mapping  for  X,  denoted  fx,  that  maps  each  variable  x  €  X  to  a  value  in  dom(x).  We  let  Fx  denote 
the  set  of  all  possible  assignment  mappings  for  X.  We  define  init(X)  to  be  the  assignment  mapping 
fx  €  Fx  such  that  Va:  €  X,  fx{x)  =  init(x).  If  X  and  Y  are  sets  of  variables  such  that  Y  C  X, 
we  define  fx\Y  to  be  the  assignment  mapping  fy  6  Fy  such  that  for  all  y  €  Y,  fy(y)  =  fx{y)>  If 
X  and  Y  are  disjoint  sets  of  variables,  and  Sx,Sy  are  sets  of  assignment  mappings  for  X  and  Y, 
respectively,  then  we  define  Sx  °Sy  to  be  the  set  of  assignment  mappings  S  for  XuY  such  that  for 
all  s  €  S,  s|A  €  Sx  and  s|F  €  Sy.  As  shorthand,  we  may  represent  a  singleton  set  of  assignment 
mappings  by  its  only  element.  For  example,  if  fx  is  an  assignment  mapping  for  X,  we  write  fx°Sy 
instead  of  {fx}  0  Sy.  Analogously,  for  fx  €  Fx  and  fy  G  Fy,  we  let  fx  °  fy  represent  its  only 
element  when  it  is  clear  from  context  that  a  mapping  (rather  than  a  set  of  mappings)  is  called  for. 
If  /  €  Fx,  x  €  X,  and  v  6  dom(x),  we  define  f[x=v]  to  be  the  assignment  mapping  /'  such  that 
/' \{X  \  {x})  =  f\(X  \  {*})  and  f'{x)  =  v. 

3.2  Shared  Memory  Actions 

Since  the  only  “sharing”  that  occurs  in  the  I/O  automaton  model  is  the  sharing  of  actions,  we 
construct  shared  memory  on  top  of  the  existing  shared  action  mechanism.  We  begin  by  defining  a 
special  type  of  action  called  a  “shared  memory  action”  that  will  be  used  to  model  accesses  to  the 
shared  variables3. 

We  fix  jC,  a  universal  set  of  access  labels.  Let  A  be  a  set  of  variables.  We  define  a  shared 
memory  action  for  A  to  be  a  triple  of  the  form  ( fx,a ,  fx),  where  fx,fx  £  Fx  and  a  €  C.4  We  let 
sm-acts( X )  denote  the  set  of  all  possible  shared  memory  actions  for  A.  We  say  that  ■k  is  a  shared 
memory  action  iff  it  is  a  shared  memory  action  for  some  A.  We  say  cr  is  a  shared  memory  step  (for 
A)  iff  its  contained  action  is  a  shared  memory  action  (for  A). 

To  construct  signatures  for  shared  memory  automata,  we  need  the  following  technical  definition. 
Let  II  be  a  set  of  actions  and  A  a  set  of  variables.  We  say  that  II  is  complete  for  A  iff  W  6  II,  if 

3In  some  sense,  this  is  the  reverse  of  what  is  often  done  to  incorporate  message  passing  into  a  shared  memory 
model.  In  UNITY  [1],  for  example,  shared  queue  variables  are  declared  to  model  “channels”  and  atomic  accesses  to 
these  shared  queues  model  “sending”  and  “receiving”  data  across  the  channels. 

*These  triples  are  action  names,  not  to  be  confused  with  the  steps  of  an  automaton. 


6 


*  A  A  A 

7T  =  (f'x,a,fx)  is  a  shared  memory  action  for  X,  then  Vfx,fx  €  Fx,(fx,a,fx)  €  IT. 

Let  X  and  Y  be  sets  of  variables  such  that  Y  C  X.  If  tt  =  (fx,a>  fx)  is  a  shared  memory  action 
for  A'",  we  define  its  projection  on  Y,  denoted  7r|y,  to  be  (fx\Y,a,  fx\Y),  a  shared  memory  action 
for  Y .  If  (3  is  a  sequence  of  actions,  all  of  whose  shared  memory  actions  are  shared  memory  actions 
for  X ,  then  we  define  (i\Y  to  be  the  sequence  that  results  from  replacing  each  shared  memory 
action  of  (3  by  its  projection  on  Y.  Projections  on  sets  of  shared  memory  actions,  signatures 
containing  shared  memory  actions,  and  sets  of  sequences  containing  shared  memory  actions  are 
defined  analogously.  If  a  =  (s',tt,s)  is  a  step  with  7T  a  shared  memory  action  for  X,  then  oj Y  is 
defined  to  be  (s'jjrlY,  5). 

3.3  Shared  Memory  Automata 

Let  X  be  a  set  of  variables,  and  let  A  be  an  I/O  automaton  all  of  whose  shared  memory  actions  are 
external  shared  memory  actions  for  X.  Let  shared-in{A)  denote  the  set  of  shared  memory  actions 
that  are  inputs  to  A,  and  let  shared-out(A )  denote  the  shared  memory  actions  that  are  outputs  of 
A.  We  say  that  A  is  a  shared  memory  automaton  for  X  iff  it  satisfies  the  following  conditions: 

1.  The  sets  of  actions  shared-in(A )  and  shared-out(A)  are  each  complete  for  X. 

2.  For  all  steps  (s',(fx,a,fx),s)  6  steps(A), 

if  ( fx,a ,  fx)  6  shared- out(  A),  then  for  all  f'x  €  Fx,  there  exists  a  state  s  and  some  fx  €  Fx 
such  that  (s',(fx>a,fx),s)  €  steps(A). 

3.  In  the  equivalence  relation  part(A),  any  two  output  actions  (fx,a,fx)  and  (fx,a,fx)  are 
elements  of  the  same  equivalence  class. 

The  first  condition  says  that  if  A  has  a  shared  memory  action  with  a  given  label  a,  then  it  has  all 
possible  shared  memory  actions  with  label  a.  For  input  actions,  this  means  that  A  must  be  prepared 
to  handle  any  value  it  may  observe  in  the  shared  variables  (since  inputs  are  always  enabled).  For 
output  actions,  this  condition  is  simply  a  technical  restriction  that  makes  composition  of  shared 
memory  automata  work  out  properly,  as  we  will  see  later.  The  condition  also  makes  describing  the 
signatures  of  shared  memory  automata  more  convenient,  since  we  need  not  list  all  the  allowable 
values  of  the  shared  variables  for  each  shared  memory  action  label  used. 

The  second  condition  says  that  for  each  shared  memory  output  step,  there  exists  a  step  from 
the  same  state  for  each  possible  assignment  of  the  shared  variables.  In  essence,  this  says  that  the 
preconditions  of  an  output  action  may  not  depend  on  the  values  of  the  shared  variables.  This 
corresponds  with  the  notion  that  one  cannot  observe  the  values  of  shared  variables  except  by 
accessing  them,  and  that  one  must  be  prepared  to  handle  any  value  that  might  be  observed. 

The  third  condition  says  that  the  equivalence  class  membership  of  an  output  action  may  not 
depend  upon  the  values  of  the  external  variables.  This  is  a  technical  condition  that  prevents 
a  nonsensical  situation  in  which  executions  must  be  “fair”  to  the  different  values  of  the  shared 
variables. 

Since  a  shared  memory  automaton  is  an  I/O  automaton,  all  the  standard  I/O  automaton 
definitions  for  executions,  schedules,  behaviors,  compos1  tion,  and  fairness  carry  over  to  shared 
memory  automata. 

Theorem  1:  The  composition  of  a  strongly  compatible  collection  of  shared  memory  automata  for 
A  is  a  shared  memory  automaton  for  X. 

Proof:  We  know  that  the  composition  of  a  strongly  compatible  collection  of  I/O  automata  is 
an  I/O  automaton.  Furthermore,  since  external  actions  of  the  components  are  external  actions 
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of  the  composition,  we  know  that  ail  of  the  shared  memory  actions  are  external  actions  in  the 
composition.  All  of  these  are  shared  memory  actions  for  X.  It  remains  to  be  shown  that  the 
composition  satisfies  the  three  conditions  imposed  on  shared  memory  automata  for  X.  Condition 
1  holds,  since  the  union  of  complete  sets  of  actions  is  clearly  a  complete  set.  For  condition  2,  we 
note  that  composition  does  not  introduce  any  new  output  actions,  nor  does  it  remove  any  existing 
output  actions.  Furthermore,  input-enabling  and  the  definition  of  composition  imply  that  for  each 
output  step  (s{,7r,s;)  of  a  component  A,,  for  all  states  s'  of  the  composition  A ,  if  s'|A,-  =  s\,  then 
there  exists  a  state  s  of  A  such  that  ($',n,s)  is  a  step  of  A.  Thus,  Condition  2  holds.  Since 
the  equivalence  relation  of  the  composition  is  the  union  of  the  individual  equivalence  relations  of 
the  components,  any  two  actions  in  the  same  equivalence  class  in  a  component  are  in  the  same 
equivalence  class  in  the  composition.  Since  the  set  of  shared  memory  output  actions  for  each 
component  is  complete,  strong  compatibility  assures  us  that  no  two  shared  memory  output  actions 
with  the  same  label  occur  in  different  classes  of  the  composition.  This  guarantees  Condition  3.  ■ 

So  far,  we  have  given  a  general  set  of  definitions  for  modelling  collections  of  modules  that  access 
shared  memory.  Our  accesses  allow  a  module  to  atomically  read  the  entire  contents  of  memory, 
perform  some  local  computation  (possibly  resulting  in  a  state  transition),  and  update  the  entire 
contents  of  shared  memory.  This  general  type  of  shared  memory  access  is,  of  course,  an  expensive 
operation  to  implement.  Therefore,  we  would  like  to  define  systems  in  which  the  shared  memory 
accesses  are  more  restricted.  For  example,  in  the  most  restricted  case,  we  might  only  allow  read  or 
write  accesses  to  single  shared  variables. 

Let  A  be  a  shared  memory  automaton  for  X ,  let  a  be  an  access  label  of  A,  and  let  x  £  X.  We 
say  that  a  is  a 

1.  read  access  to  x  iff  \/(s',  (/',  a,  /),  s)  €  steps(A), 

(a)  f  ~  f  and 

(b)  V/  €  Fx  such  that  f(x)  =  /'(x),  ( s',(f,a,f),s )  e  steps(A). 

2.  write  access  to  x  with  value  v  iff  V(s',(//, a, /),.?)  £  steps(A), 

0)  /  =  f(x=v]  and 

(b)  V/  <=  Fx,  (s\(f,aj[x=v]),s)  €  steps(A). 

In  a  read  access  to  x,  the  shared  memory  is  unmodified  and  the  new  state  of  A  depends  only 
upon  the  value  observed  in  variable  x.  In  a  write  access  to  x,  the  “before”  and  “after”  states  of 
shared  memory  differ  only  in  the  value  of  variable  a;,  and  the  new  state  of  A  and  the  new  value  of 
x  are  independent  of  the  “before”  state  of  shared  memory. 

We  now  define  a  restricted  class  of  shared  memory  automata  called  “single-variable  read-write 
automata.”  In  such  automata,  each  access  label  for  a  shared  memory  output  is  constrained  to  be  a 
read  access  or  a  write  access  to  a  single  variable.  Let  A  be  a  shared  memory  automaton  for  X,  and 
let  ip  be  a  partition  of  the  access  labels  for  actions  in  shared-out(A )  such  that  there  exist  exactly 
two  classes  in  ip  for  each  variable  in  x  G  X,  denoted  ipr(x)  and  ipw(x).  The  partition  ij>  is  called  the 
access  partition  of  A.  We  say  that  A  is  a  single-variable  read-write  automaton  under  ib  iff  Vx  €  X , 
ipT{x)  contains  only  read  accesses  to  x  and  ipw(x)  contains  only  write  accesses  to  x.  We  say  that 
such  an  automaton  can  read  x  iff  ipr(x)  is  nonempty,  and  can  write  x  iff  ipw(x)  is  nonempty.  If  Q  is 
a  collection  of  single- variable  read-write  automata,  then  a  component  of  Q  is  said  to  own  a  variable 
x  if  it  is  the  only  component  that  can  write  x;  in  this  case,  x  is  said  to  be  a  single-writer  variable. 
Multi- writer,  single-reader ,  and  multi-reader  variables  are  defined  in  the  obvious  way. 
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Other  classes  of  shared  memory  automata  could  be  constructed  in  a  similar  manner.  For 
example,  one  might  define  test-and-set  or  memory-to-memory-swap  accesses  and  define  automata 
in  which  the  access  labels  are  appropriately  partitioned  into  additional  claves.  In  fact,  this  style  of 
definition  can  be  used  to  define  shared  memory  accesses  for  operations  on  arbitrary  data  types,  such 
as  enqueue  and  dequeue.  Of  course,  any  shared  memory  algorithm  could  be  expressed  and  studied 
using  the  general  shared  memory  automaton  definition  only,  but  being  specific  about  the  types  of 
shared  memory  accesses  allowed  makes  the  assumptions  about  the  underlying  shared  memory  more 
explicit,  and  also  may  help  simplify  reasoning  about  the  algorithm. 

3.4  Augmentation  and  Augmented-Composition 

In  building  up  I/O  automaton  systems,  we  may  wish  to  compose  collections  of  shared  memory 
automata  having  different  (either  intersecting  or  disjoint)  sets  of  shared  variables.  We  would  like 
the  result  of  this  composition  to  be  a  shared  memory  automaton  for  Z,  where  Z  is  the  union  of 
the  sets  of  shared  variables  of  the  automata  being  composed.  In  order  to  accomplish  this,  we  first 
“augment”  each  of  the  automata  with  additional  shared  variables  so  that  its  set  of  shared  variables 
is  Z.  Then  we  compose  as  usual.5 

We  now  define  what  is  meant  by  augmenting  an  automaton.  Let  X  and  Z  be  sets  of  variables, 
with  X  C  Z.  Given  a  shared  memory  automaton  A  for  X,  we  define  augment(A,  Z),  read  “the 
augmentation  of  A  to  Z,”  to  be  the  automaton  B  as  follows: 

•  in(B)  =  {7r  6 sm-acts(Z) :  ir\X  €shared-in(A)}  U 
( in(A)\shared-in(A )). 

•  out(B)  =  {it  £$m-acts(Z)  :  ir|X  Gshared-out(A)}  U 
( out(A)\shared-out(A )). 

•  int(B)  =  int(A). 

•  states(B)  =  states(A). 

•  start(B)  =  start(A). 

•  steps(B)  =  all  steps  a  =  (s',  tt,s)  such  that  either 

1.  o  €  steps(A)  and  tt  is  not  a  shared  memory  action,  or 

2.  a \X  €  steps(A)  and  tt  &shared-in(B),  or 

3.  <t\X  e  steps(A),  7 r  =  (fz,a,fz)  €shared-out(B ),  and  f'z\(Z  -  X)  =  fz\(Z  -  X). 

•  part(B)  =  {C  C  local(B)  :  C\X  €  part(A)}  such  that  part(B)  forms  a  partition  of  the 
locally-controlled  actions  of  B. 

Essentially,  we  augment  A  by  making  the  signature  complete  for  Z,  while  leaving  the  set  of  states 
unchanged.  For  each  step  involving  a  shared  memory  action  7r  for  X,  we  substitute  the  set  of  all 
steps  in  which  7r  is  replaced  by  a  shared  memory  action  for  Z  (call  it  7r')  such  that  7r'|X  =  7r.  For 
output  actions  steps,  we  make  the  further  restriction  that  if  it'  =  (/£,  u,  fz),  then  f'z  and  fz  differ 
only  in  their  assignments  to  the  variables  of  X.  This  models  the  fact  that  outputs  of  B  only  change 
the  values  of  shared  variables  in  X.  We  do  not  make  this  restriction  for  input  actions  because 

SWhen  composing  a  shared  memory  automaton  with  an  “ordinary”  I/O  automaton,  no  augmentation  is  necessary, 
since  an  ordinary  I/O  automaton  is  by  definition  an  SMA  for  any  set  of  variables  X. 


9 


they  are  always  enabled.  This  also  highlights  the  fact  that  the  shared  memory  accesses  of  B  are 
independent  of  all  shared  variables  other  than  those  in  X.  The  partition  of  B  is  constructed  from 
that  of  A  to  reflect  the  differences  in  their  signatures. 

Theorem  2:  Let  X  and  Z  be  sets  of  variables,  with  X  C  Z,  and  let  A  be  a  shared  memory 
automaton  for  X ,  Then  augment(A,  Z)  is  a  shared  memory  automaton  for  Z. 

Proof:  Immediate  from  the  definitions  of  augmentation  and  shared  memory  automata.  ■ 

Our  next  result,  Theorem  5,  says  that  augmentation  does  not  (in  any  significant  way)  affect  the 
behavior  of  an  automaton.  This  is  proved  using  the  following  lemmas. 

Lemma  3:  Let  X  and  Z  be  sets  of  variables  such  that  X  C  Z.  If  A  is  a  shared  memory  automaton 
for  X  and  a  a  is  an  execution  of  A ,  then  there  exists  an  execution  of  B  —  augment(A,  Z)  such 
that  aB \X  =  a  a . 

Proof:  Clearly,  if  c*a  contains  no  actions,  the  claim  holds.  For  the  inductive  hypothesis,  let 
oca  =  oi'a^as  be  an  execution  of  A,  and  let  a'B  be  the  execution  of  B  such  that  a'B |X  =  a'A. 
Clearly  the  state  of  A  after  a'A  is  the  same  as  the  state  of  B  after  a'B.  Let  this  state  be  s'.  It 
remains  to  be  shown  that  some  rrg  is  enabled  from  s'  in  B,  resulting  in  state  s,  where  t:b\X  =  7^. 
If  tta  is  not  a  shared  memory  action,  then  the  result  is  trivial,  since  the  steps  of  A  and  B  differ 
only  with  respect  to  shared  memory  actions.  If  tta  is  a  shared  memory  action  (/^,  a,  fx),  then  by 
the  definition  of  augmentation,  there  must  be  a  step  (s',nB  =  {f'z,a,  fz),$)  €  steps(B)  such  that 
nB\X  =  tca-  u 

Lemma  4:  Let  X  and  Z  be  sets  of  variables  such  that  X  C  Z.  If  A  is  a  shared  memory  automaton 
for  X  and  aB  is  an  execution  of  B  -  augment(A,  Z),  then  there  exists  an  execution  aA  of  A  such 
that  aA  =  aB\X. 

Proof:  If  aB  has  no  actions,  the  claim  holds.  For  the  inductive  hypothesis,  let  aB  =  a 'bttbs 
be  an  execution  of  B,  and  let  a'A  be  the  execution  of  A  such  that  a'A\X  -  a'A.  Clearlv  the  state 
of  B  after  a'B  is  the  same  as  the  state  of  A  after  a'A.  Let  this  state  be  s'.  It  remains  to  be  shown 
that  some  tta  is  enabled  from  s'  in  A,  resulting  in  state  s,  where  tta  =  kb\X.  If  irB  is  not  a  shared 
memory  action,  then  the  result  is  trivial  as  before.  If  nB  is  a  shared  memory  action  {fz,a,fz), 
then  by  the  definition  of  augmentation,  the  step  ( s',(fz\X,a,fz\X),s )  €  steps(A).  Therefore,  the 
second  claim  holds.  ■ 

Theorem  5:  Let  X  and  Z  be  sets  of  variables  such  that  X  C  Z.  If  A  is  a  shared  memory 
automaton  for  X ,  then 

1.  behs(augment(A,  Z))\X  =  behs(A),  and 

2.  fairbehs(augment(A,  Z))\X  =  fairbehs(A). 

Proof:  Part  1  is  immediate  from  Lemmas  3  and  4. 

For  Part  2,  let  aA  be  a  fair  execution  of  A ,  and  let  0a  =  beh(aA).  From  Lemma  3,  we  know 
that  there  exists  an  execution  aB  of  B  =  augment(A,  Z)  such  that  aB\X  =  aA.  To  show  that 
aB  is  fair,  we  apply  the  definition  of  augmentation.  From  the  construction  of  steps(B),  a  shared 
memory  action  7 r  e  octs(B)  is  enabled  in  state  .?  of  B  only  if  tt\X  is  enabled  in  st.a.te  s  of  A.  The 
remaining  actions  7r  €  acts(B)  are  enabled  in  in  state  s  of  B  only  if  7r  is  enabled  in  state  s  of  A. 
Furthermore,  any  two  actions  it  and  tt'  are  in  the  same  equivalence  class  of  B  iff  n\X  and  it'\X  are 
in  the  same  equivalence  class  of  A.  So,  since  oa  is  fair,  aB  is  fair. 

Now,  to  show  the  oth  r  direction,  let  aB  be  a  fair  execution  of  B.  By  Lemma  4,  there  exists  an 
execution  a  a  of  A  such  that  a  a  =  aB\X.  To  show  that  a  a  is  fair,  we  argue  similarly  to  above.  ■ 
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We  can  now  define  augmented-composition,  making  use  of  the  augmentation  definition  and  stan¬ 
dard  I/O  automaton  composition. 

Augmented-Composition:  Let  {X,-},-gj  be  a  collection  of  (not  necessarily  disjoint)  sets  of  vari¬ 
ables,  let  Z  —  11,-gjX,-,  let  each  A,-  be  a  shared  memory  automaton  for  X;,  and  let  the  collection 
{augment(A;)}ie!  be  strongly  compatible.  We  define  the  augmented  composition  A,-  to  be  the 
ordinary  I/O  automaton  composition  Flf &  augment (A{,  Z). 

Theorem  6:  Let  {A'’;},-gj  be  a  collection  of  (not  necessarily  disjoint)  sets  of  variables,  let  Z  = 
U ,-g/X,-,  let  each  A,'  be  a  shared  memory  automaton  for  X;,  and  suppose  that  the  collection  of 
automata  {augment(A{,  Z)}ieI  is  strongly  compatible.  Then  the  augmented  composition 
is  a  shared  memory  automaton  for  Z. 

Proof:  By  Theorem  2,  for  each  A,-,  avgnient(A{ ,  Z)  is  a  shared  memory  automaton  for  Z. 
Therefore,  by  Theorem  1,  the  result  holds.  ■ 

The  following  three  compositionality  results  follow  immediately  from  the  corresponding  results  in 
[8],  together  with  Theorems  5  and  6.  The  first  result  says  that  an  execution  of  an  augmented- 
composition  induces  executions  of  the  component  shared  memory  automata. 

Corollary  7:  Let  {X{}ieI  be  a  collection  of  sets  of  variables,  where  Z  =  U,-gjX,\  Let  {A,},-g/  be  a 
collection  of  automata  such  that  each  A,-  is  a  shared  memory  automaton  for  X,-.  Let  the  collection 
of  automata  {augment(Ai,Z)}i€l  be  strongly  compatible,  and  let  A  =  If  <*  £  execs(A) 

then  (a\augment(Ai,  Z))\X{  G  execs  (AQ  for  every  i  G  I.  Moreover,  the  same  result  holds  if  execsQ 
is  replaced  by  fairexecsQ,  schedsQ,  fairschedsQ,  behsQ,  or  fairbehsQ. 

The  next  result  says  that  executions  of  component  shared  memory  automata  can  often  be  pasted 
together  to  form  an  execution  of  the  augmented-composition. 

Corollary  8:  Let  {X,-}jgJ  be  a  collection  of  sets  of  variables,  where  Z  =  U,-g/X,\  Let  {A,-};g/  be  a 
collection  of  automata  such  that  each  A,-  is  a  shared  memory  automaton  for  X,-.  Let  the  collection 
of  automata  {augment(Ai,  Z)}ieI  be  strongly  compatible,  and  let  A  =  Y\feIAi.  Suppose  a,-  is  a 
(fair)  execution  of  A,-  for  every  i  G  I,  and  let  /?  be  a  sequence  of  actions  in  acts[A)  such  that 
(P\augment(Ai,  Z))\Xi  =  sched(ai )  for  every  i  G  I.  Then  there  is  a  (fair)  execution  a  of  A  such 
that  fi  =  sched(a)  and  a,-  =  (a\augment(A{,  Z))\X;  for  every  i  G  I.  Moreover,  the  same  result 
holds  when  actsQ  and  scheds{ )  are  replaced  by  ext()  and  beh{). 

Finally,  schedules  and  behaviors  of  component  shared  memory  automata  can  also  be  pasted  together 
to  form  schedules  and  behaviors  of  the  augmented-composition. 

Corollary  9:  Let  {X,-},-g/  be  a  collection  of  sets  of  variables,  where  Z  =  U,-g/X,\  Let  {A.}tg/ 
be  a  collection  of  automata  such  that  each  A;  is  a  shared  memory  automaton  for  X;.  Let  the 
collection  of  automata  {augment(A{,  Z)}{eI  be  strongly  compatible,  and  let  A  =  f] t&Ai-  Tet  (3 
be  a  sequence  of  actions  in  acts{A).  If  (P\augment(Ai,  Z))\X{  G  scheds(Ai)  for  every  i  G  /,  then 
P  G  sckeds(A).  Moreover,  the  same  result  holds  when  nctsQ  and  srheHsQ  are  replaced  by  ext.() 
and  behsQ ,  respectively,  and  similarly  when  replaced  by  acts( )  and  fairscheds( )  or  by  ext()  and 
fairbehsQ. 
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3.5  The  Closeout  Operator 

So  far,  we  have  introduced  shared  memory  actions  to  model  accesses  to  shared  variables,  and  we 
have  defined  a  special  kind  of  I/O  automaton  containing  shared  memory  actions  >n  its  signature. 
We  have  interpreted  the  first  triple  of  each  action  as  the  “before  state”  of  shared  memory  and 
the  third  component  as  the  “after  state.”  However,  we  have  not  yet  placed  any  restrictions  on 
the  the  relationship  between  the  “after  state”  of  one  shared  memory  action  and  the  “before  state” 
of  the  next.  A  shared  memory  automaton  is  not  guaranteed  that  the  value  it  writes  to  a  given 
shared  variable  will  be  the  value  observed  by  the  next  system  component  reading  that  variable.  In 
other  words,  we  permit  the  environment  to  freely  modify  the  values  in  shared  memory.  We  would 
like  to  construct  systems  in  which  the  set  of  components  that  may  modify  a  particular  shared 
variable  is  fixed,  closed  to  the  environment.  We  therefore  define  a  “closeout”  operator,  which  takes 
a  shared  memory  automaton  A  and  produces  a  new  automaton  B  such  that  some  or  all  of  the 
shared  variables  of  A  become  part  of  the  local  state  of  B.  In  this  way,  the  “absorbed”  variables  can 
be  touched  only  the  by  the  actions  of  B.  Since  A  may  be  the  result  of  composing  several  shared 
memory  automata,  the  closeout  operator  achieves  the  desired  result  of  restricting  shared  variable 
accesses  to  a  particular  collection  of  system  modules. 

We  now  define  the  closeout  operator  C.  Since  the  state  of  an  automaton  may  be  thought  of  as 
a  mapping  from  a  set  of  variables  to  a  set  of  values,  we  will  feel  free  to  operate  on  states  as  if  they 
were  assignment  mappings.  Let  X  and  Y  be  disjoint  sets  of  variables,  let  Z  =  X  U  Y,  and  let  A  be 
a  shared  memory  automaton  for  Z.  We  define  B  —  C(A,X)  as  follows: 

•  sig(B)  =  sig(A)\Y 

•  states(B)  =  states(A)  o  Fx , 

•  start(B)  =  start(A)  o  init(X), 

•  steps(B)  contains  exactly  the  following  set  of  steps:  for  each  step  (s',n,s)  in  steps(A), 

1.  if  7r  =  ( f'z,a ,  fz)  is  a  shared  memory  action,  then 
(s'  o  (f'z\X),  ( f'z\Y ,  a,  fz\Y),  s  o  (fz\X))  6  steps(B), 

2.  if  7r  is  not  a  shared  memory  action,  then 

{(s'  o  fx,  a,  s  o  fx) :  fx  6  Fx}  C  steps(B),  and 

•  part(B)  =  part(A),  where  each  class  is  projected  on  Y. 

Essentially,  the  variables  in  X  are  absorbed  into  the  internal  state  of  the  “closed  out”  automaton. 
If  x  €  X,  we  use  the  familiar  record  notation  s.x  to  refer  to  the  value  of  x  in  a  particular  state  s 
of  B.  That  is,  if  sb  =  sa  °  fx ,  where  5,4  is  a  state  of  A,  then  sg.x  =  fx(x). 

Given  the  definition  of  the  closeout  operator,  we  get  the  following  natural  result. 

Theorem  10:  Let  A  be  a  shared  memory  automaton  for  Z  and  let  X  and  Y  be  disjoint  sets  of 
variables  such  that  Z  -  X  UY.  Then  B  =  C(A,X )  is  a  shared  memory  automaton  for  Y. 

Proof:  To  show  that  B  is  an  I/O  automaton,  we  must  demonstrate  that  for  all  states  s'  and 
input  actions  n  of  B,  there  exists  a  state  s  of  B  such  that  (s',  k,  s )  fc  steps(B).  Since  this  property 
is  true  of  A ,  and  since  shared-in(A )  is  complete,  this  property  is  also  true  of  B  by  the  construction 
of  steps(B).  (When  we  construct  the  steps  of  B,  completeness  of  shared-in(A)  guarantees  that  we 
include  all  possible  values  for  X  in  the  “before  states”  of  the  steps  for  each  input  action.) 

We  now  show  that  I/O  automaton  B  is  a  shared  memory  automaton  for  Y.  Clearly,  all  the 
shared  memory  actions  of  B  are  external  shared  memory  actions  for  Y .  We  now  show  that  each 
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of  the  three  conditions  in  the  definition  of  a  shared  memory  automaton  hold  for  B.  For  the  first 
condition,  since  shared-in(A)  is  complete  for  Z ,  shared-in(B)  =  shai-ed-in(A)\Y  must  be  complete  for 
Y.  Similarly,  for  shared-out(B).  The  second  condition  requires  that  for  every  step  (s',  ( fy,a ,  /y),s) 
in  steps(B),  if  (/y,a,  fy)  £  shared- out(B),  then  for  all  fy  €  Fy,  there  exists  a  state  s  and  some 
fy  €  Fy  such  that  (s',  (/y,  a,  fy),  s)  is  in  steps(B).  Since  this  condition  is  true  for  A,  we  know  that 
for  each  shared  memory  output  action  label  a,  there  exists  a  step  (s',  (fx  o  fy,a,fx  0  fy),$)  for 
every  possible  assignment  mapping  fx  o  fy  for  Z.  Therefore,  when  we  project  on  Y  in  constructing 
steps(B),  we  have  a  step  (s',  (fy,a,  fy),s)  for  each  possible  assignment  mapping  fy  for  Y.  The 
third  condition,  regarding  membership  of  equivalence  classes,  is  obviously  true  of  B.  * 

3.6  Closeout  for  behaviors 

We  now  give  a  closeout  definition  for  behaviors  that  is  analogous  to  the  one  for  automata. 

Let  X  and  Z  be  sets  of  variables  with  X  C  Z.  If  (3  is  a  sequence  of  actions  of  a  shared  memory 
automaton  A  for  Z,  then  we  say  that  (5  is  consistent  for  X  iff  the  following  conditions  hold: 

1.  if  (f'z,a,fz)  is  the  first  shared  memory  action  in  0,  then  fz\X  =  init(X),  and 

2.  if  (fz',ai,fz)  and  (/z,  ct2>  /z)  are  shared  memory  actions  in  0  such  that  no  shared  memory 
action  occurs  between  them,  then  fz\X  =  f'z\X. 

If  S  is  a  set  of  sequences  of  actions  of  a  shared  memory  automaton  for  Z,  then  we  define  C(S,X) 
to  be  the  set  T,x\{Z  —  X),  where  Zx  is  the  subset  of  E  containing  exactly  tho.>e  sequences  that  are 
consistent  for  X. 

Lemma  11:  Let  X  and  Z  be  sets  of  variables  such  that  X  C  Z.  Let  A  be  a  shared  memory 
automaton  for  Z,  and  let  as  be  an  execution  of  B  =  C(A,X)  with  behavior  0b-  Then  there  exists 
an  execution  aA  of  A,  with  behavior  0A  consistent  for  X,  such  that  0A\(Z  -  X)  =  03- 

Proof:  Let  y  =  Z  —  X.  We  construct  the  sequence  aA  from  ocb  as  follows.  For  each  step 
(s'  o  f'x,TC,s  o  fx )  in  o>b,  if  n  =  ( fy,a,fy )  is  a  shared  memory  action  of  B,  then  we  let  the 
corresponding  step  in  aA  be  (s',  (/y  o  fx,a,fy  o  fx),$)\  and  if  7r  is  not  a  shared  memory  action, 
we  let  the  corresponding  step  in  aA  be  (s',7r,s). 

Let  0b  =  beh(aA).  Clearly,  0b\Y  =  0A.  It  remains  to  be  shown  that  aA  is  an  execution 
of  A  and  that  0A  is  consistent  for  X .  We  show  that  aA  is  an  execution  of  A  by  showing  that 
each  step  of  aA  is  in  s<eps(A).  Let  a  =  (s'  o  fx,n,s  o  fx)  be  a  step  of  B.  If  n  =  ( fy,a,fy )  is 
a  shared  memory  action  of  B,  then  by  the  construction  of  steps(B)  in  the  definition  of  closeout, 
(s\  (fy  0  f'xi  ai  fy  0  fx),  5)  must  be  a  step  of  A.  Similarly,  if  n  is  not  a  shared  memory  action,  then 
(s',  7r,  s)  must  be  a  step  of  A.  Therefore,  the  construction  produces  an  execution  of  A. 

Finally,  we  show  that  0A  is  consistent  for  X.  Since  every  initial  state  of  C(A,X)  is  in  staies(A)o 
init(X),  it  must  be  that  the  first  shared  memory  action  {f'z,a,fz)  of  0b  has  f'\X  =  init(X),  so 
the  first  consistency  condition  is  satisfied  We  know  that  the  second  consistency  condition  must 
be  satisfied,  since  any  two  successive  steps  (s'",  7Ti ,  s")  and  (s',7T2,s)  of  any  execution  must  have 
s"  =  s',  the  assignments  to  the  variables  of  X  are  part  of  the  state  of  C(A,  X),  and  the  only  actions 
that  may  change  the  values  for  X  in  the  state  of  C{A,X)  correspond  to  shared  memory  actions  for 
for  Z.  m 

Lemma  12:  Let  X  and  Z  be  sets  of  variables  such  that  X  C  Z.  Let  A  be  a  shared  memory 
automaton  for  Z  and  ret  aA  be  an  execution  of  A  with  behavior  0A.  If  0A  is  consistent  for  X,  then 
there  exists  an  execution  as  of  B  —  C(A,  X)  such  that  0A\(Z  -  X)  is  the  behavior  of  as- 
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Proof:  Let  Y  —  Z  ~  X.  Let  ag  be  the  execution  constructed  from  as  follows.  For  each 
shared  memory  action  ir  in  04,  let  the  coiresponding  action  in  ag  be  7rj Y.  Leave  the  remaining 
actions  as  in  a^.  For  each  state  s  in  ax,  let  the  corresponding  state  in  ag  be  so(/2|X),  where  fz 
is  the  third  component  of  the  preceding  shared  memory  action  in  a  a  (or  fz  =  init(Z)  if  there  is 
no  preceding  shared  memory  action). 

Clearly  Pa\Y  =  beh(as)‘  We  claim  that  ag  is  an  execution  of  B.  To  prove  this  claim,  we 
proceed  by  induction  on  the  length  of  ag,  showing  that  each  action  is  enabled  from  the  state  in 
which  it  occurs.  Clearly,  if  ag  contains  no  actions,  then  the  claim  holds.  Let  ( s'A ,  tt,  S4)  be  a  step  of 
a  a,  and  let  a'B  be  the  portion  of  ag  up  to  (but  not  including)  the  action  7r|  Y  for  the  corresponding 
step  in  ag.  We  wish  to  show  that  if  a'B  ends  in  state  s'B>  then  the  step  (sg,7r| Y,sg)  €  steps(B), 
where  sg  is  the  next  state  of  ag.  By  the  construction,  we  know  that  sB  =  s'A  o  (fz\X),  where  f'z 
is  the  third  component  of  the  preceding  shared  memory  action  in  a. a  (or  fz  =  init(Z)  if  there  is 
no  preceding  shared  memory  action),  and  similarly  for  sg.  There  are  two  cases  for  7r: 

1.  If  7T  is  not  a  shared  memory  action,  then  clearly  it  is  enabled  from  s'B,  since  (by  the  construc¬ 
tion)  s'A  and  $'B  are  identical  except  that  $'A  does  not  assign  values  to  the  variables  in  X. 
Furthermore,  since  ir  is  not  a  shared  memory  action,  sg|X  =  3g|AT,  so  the  step  exists  by  the 
definition  of  the  closeout  operator. 

2.  If  7r  =  (fz,a,fz)  is  a  shared  memory  action,  then  consistency  of  /3A  requires  that  f'z  be 

the  third  component  of  the  preceding  shared  memory  action  in  <xa  (or  init(Z)  if  there  is  no 
such  preceding  action).  By  the  definition  of  closeout,  we  know  steps(B)  contains  the  step 
(s'a  0  (fz\Y,a,fz\Y),  sA  o  ( fz\X )).  And  by  the  construction,  s'A  o  ( f'z\X )  =  s'B  and 

sA  o  (fz\X)  =  sb-  Therefore,  the  desired  step  exists. 

In  both  cases,  n\Y  is  enabled  and  leads  to  state  sB.  ■ 

Theorem  13:  Let  X  and  Z  be  sets  of  variables  such  that  X  C  Z.  If  A  is  a  shared  memory 
automaton  for  Z ,  then 

1.  behs(C(A,X))  =  C(behs(A),X),  and 

2.  fairbehs(C(A,  X))  =  C{fairbehs{A),X). 

Proof:  Part  1:  Let  Y  —  Z  —  X .  By  Lemma  11,  we  know  that  if  j. 3\Y  is  a  behavior  of  C(A,  X), 
then  /?  is  a  behavior  of  A  that  is  consistent  for  X.  Therefore  P]Y  €  C(behs(A),X),  by  definition.  If 
(3\Y  €  C(behs(A),X)>  then  by  definition  of  closeout  on  behaviors,  (3  is  consistent  for  X.  Therefore, 
Lemma  12  tells  us  that  /3\ Y  6  behs(C(A,X)). 

Part  2:  First,  we  show  that  fairbehs(C(A,X ))  contains  C(fairbehs(A),X).  Let  /?g  be  a  fair 
behavior  of  B  =  C(A,X),  and  let  as  be  an  execution  of  B  with  beh(as)  =  Pb-  Construct 
execution  04  of  A  from  ag  as  in  the  proof  of  Lemma  11  such  that  beh(aA)\(Z  -  X)  =  /?g.  Since 
A  is  a  shared  memory  automaton,  we  know  that  shared-oui(A)  is  complete  and  that  for  any  given 
access  label  a  €  £,  all  shared  memory  actions  with  label  a  belong  to  the  same  class.  Furthermore, 
by  the  definition  of  closeout,  7Ta  and  7 rA  belong  to  the  same  equivalence  class  in  A  iff  ka\X  and. 
7r'j|X  belong  to  the  same  equivalence  class  in  B.  Therefore,  given  that  ag  is  fair,  we  can  show 
that  04  is  fair  by  arguing  that  an  action  7 ta  is  enabled  in  state  S4  of  a  a  iff  ka\X  is  enabled  in 
the  corresponding  state  sg  of  ag.  This  is  easily  seen  from  the  construction  of  steps(B).  since 
«a  =  *b\(Z-X). 

Now,  we  show  that  C(fairbehs(A),X )  contains  the  set  fairbehs(C{A,X)).  Let  Pa  be  a  fair 
behavior  of  A  that  is  consistent  for  X,  and  let  a  a  be  an  execution  of  A  with  beh(aA )  =  Pa- 
Construct  execution  ag  of  C(A,  X)  from  a  a  as  in  the  proof  of  Lemma  12  such  that  Pa\(Z  -  X)  = 
beh(aB).  The  remainder  of  the  proof  is  argued  as  above.  ■ 
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3.7  Discussion 

Important  in  defining  our  shared  memory  extensions  were  the  built-in  features  of  the  I/O  automaton 
model,  most  notably  composition  and  the  separation  of  inputs  and  outputs.  By  using  the  built-in 
notion  of  an  output  action  being  under  the  control  of  a  single  process,  we  werj  able  to  capture 
the  idea  of  a  single  module  making  an  atomic  update  to  shared  memory  (without  any  active 
participation  by  other  modules).  In  addition,  by  exposing  the  values  of  the  shared  variables  as 
part  of  the  shared  memory  accesses,  we  were  able  to  not  only  carry  forward  the  compositionality 
properties  of  I/O  automaton  behaviors  but  also  provide  a  useful  notion  of  a  shared  memory  action 
as  an  input.  We  expect  normal  communication  through  shared  variables  to  be  modeled  using 
output  actions  only,  but  the  input  actions  allow  a  module  to  passively  observe  the  accesses  to 
shared  memory  made  by  other  processes.  We  see  two  potential  uses  for  this  feature.  First,  one 
might  use  shared  memory  actions  as  inputs  to  construct  external  processes  that  are  not  part  of 
the  algorithm  but  monitor  the  use  of  shared  memory  (possibly  as  a  means  to  check  algorithms  in 
a  simulation  system).  Second,  in  a  modular  algorithm  design,  it  may  be  appropriate  to  divide  a 
task  into  several  I/O  automaton  components  such  that  only  one  component  accesses  the  shared 
memory  while  the  others  are  kept  “informed”  of  these  accesses  by  receiving  them  as  inputs  (e.g., 
to  model  a  collection  of  processes  “snooping”  on  a  memory  bus  to  update  local  caches). 

4  Example:  Dijkstra’s  mutual  exclusion  algorithm 

In  order  to  illustrate  the  shared  memory  extensions  just  presented,  we  apply  them  to  Dijkstra’s 
classical  shared  memory  mutual  exclusion  algorithm.  We  begin  by  defining  the  mutual  exclusion 
problem  in  terms  of  the  I/O  automaton  model.  We  then  present  Dijkstra’s  algorithm  as  a  compo¬ 
sition  of  shared  memory  automata.  The  safety  and  progress  proofs  that  follow  demonstrate  how 
proofs  using  standard  assertional  techniques  may  be  expressed  straightforwardly  using  this  model. 

4.1  The  Mutual  Exclusion  Problem 

Fix  n,  a  positive  integer,  and  let  X  =  {1,2, We  define  schedule  module  M  with  S2p(M)  as 
follows: 

Inputs:  UserTry;,  t  e X  Outputs:  Crit ;,i€Z 
UserExit;,  i  €  X  Rem;,  i  €  X 

Schedule  module  M  interacts  with  an  environment  that  may  be  thought  of  as  a  collection  of  n 
user  processes  u;,  i  €  X,  where  each  process  it;  has  outputs  UserTry;  and  UserExit;,  and  has  inputs 
Crit;  and  Rem;.  A  UserTry;  action  means  that  process  u;  wishes  to  enter  its  critical  section.  A 
Crit;  action  by  M  gives  r,;  permission  to  enter  its  critical  section.  A  UserExit;  action  means  that 
process  «;  is  leaving  its  critical  section.  Finally,  the  Rem;  action  gives  «;  permission  to  continue 
with  the  remainder  of  its  program.  If  (3  is  a  sequence  of  actions  of  M,  then  we  define  (3\i  to  be 
the  subsequence  of  f 3  containing  exactly  the  UserTry;,  Crit;,  UserExit;,  and  Rem;  actions.  Before 
lefining  the  allowable  schedules  of  M,  we  define  the  set  of  well-formed  and  user-live  sequences  of 
actions  of  M .  Let  Q  be  a  sequence  of  actions  in  sip(M).  We  say  that  (3  is  well-formed  ill  for  all  i  6  T, 
all  prefixes  of  j3\i  are  prefixes  of  the  infinite  sequence  UserTry;,  Crit;,  UserExit;,  Rem;,  UserTry;, 
Crit;,. . ..  This  says,  for  example,  that  a  process  will  not  issue  a  try  request  while  in  its  critical 
section.  If  /?  is  a  sequence  of  actions  of  S,  we  say  that  j3  is  user-live  iff  for  all  i  €  X,  (3\ i  is  either 
infinite  or  does  not  end  with  Crit;.  Informally,  this  says  that  no  user  «;  stops  in  its  critical  section. 
An  execution  is  said  to  be  well-formed  (user-live)  iff  its  behavior  is  well-formed  (user-live). 
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We  define  the  set  scheds( M),  the  allowable  external  behaviors  of  M,  as  follows.  Let  ft  be  a 
sequence  of  actions  in  st£r(M).  Then  ft  €  scheds(M)  iff  the  following  conditions  hold: 

1,  M  preserves  well-formedness  in  ft. 

2.  If  ft  is  well-formed,  then 

(a)  (mutual  exclusion)  Vi,  j  €  2,  if  Crit,'  and  Critj  occur  in  ft  (in  that  order),  then  UserExit,- 
occurs  between  them. 

(b)  (progress)  if  ft  is  user-live,  then  either  ft  is  infinite  or  Vi,/?|i  ends  with  Rem,-. 

Condition  (2a)  is  the  safety  property:  no  two  processes  axe  in  their  critical  sections  simulta¬ 
neously.  Condition  (2b)  is  the  progress  property:  either  all  processes  eventually  end  up  in  their 
remainder  regions  or  some  process  enters  the  critical  region  infinitely  often.  Both  properties  are 
guaranteed  only  if  the  user  processes  preserve  well-formedness,  and  the  progress  condition  is  guaran¬ 
teed  only  if  user  processes  eventually  exit  the  critical  region.  In  this  variant  of  the  mutual  exclusion 
problem,  only  a  very  weak  progress  requirement  is  made.  For  example,  correct  solutions  to  this 
problem  admit  executions  in  which  a  process  is  locked  out  of  the  critical  section. 

4.2  Dijkstra’s  Mutual  Exclusion  Algorithm 

In  this  section,  we  model  Dijkstra’s  shared  memory  mutual  exclusion  algorithm  [2]  as  an  il¬ 
lustration  of  our  shared  memory  extensions  to  the  I/O  automaton  model.  As  presented  here,  the 
variable  names  and  structure  more  closely  follow  the  description  in  [6],  although  the  algorithm  is 
the  same. 

We  implement  schedule  module  M  by  a  collection  of  n  automata  p{,  i  e  X,  where  each  p; 
interacts  with  u,-  through  shared  actions  and  interacts  with  the  other  p/s  using  shared  variables. 
Each  Pi  has  three  state  components:  stage  €  {try,  read,  check,  set,  control,  final-check,  failed,  crit, 
exit,  done,  remainder};  k,  an  integer  in  the  range  1  to  n;  and  checked ,  a  set  of  integers  in  the  range 
1  to  «.  Initially,  stage  =  remainder,  k  is  arbitrary,  and  checked  is  the  empty  set.  Automaton  p,-  is  a 
shared  memory  automaton  for  V,  where  V  has  the  following  variables:  k,  an  integer  in  the  range  1 
to  re;  and  control[j]  for  j  <E  X,  which  take  on  values  from  {0,1,2}.  Initially,  k  has  an  arbitrary  value 
and  all  control  variables  are  0.  The  code  for  automaton  p;  is  shown  in  Figure  1.  Shared  memory 
actions  are  listed  by  their  access  labels  and  distinguished  by  daggers  (f);  all  other  actions  are  listed 
by  their  action  names.  All  actions  of  p,-  are  outputs,  except  User  Try,-  and  UserExit,-,  which  are 
its  inputs.  “Pre”  and  “Eff”  denote  “precondition”  and  “effect”,  respectively.  For  shared  memory 
actions,  the  step  (s',  (v',a,v),s)  is  in  steps(pi )  exactly  when  the  precondition  for  a  is  satisfied  in 
state  s’  and  s  and  v  are  derived  from  s'  and  v'  according  to  the  effect  clause.  For  all  other  output 
actions,  the  step  (s',ir,s)  is  in  steps(pi)  exactly  when  the  precondition  for  ir  is  satisfied  in  state  s' 
and  state  s  is  derived  from  state  s'  according  to  the  effect  clause.  If  an  action  has  no  precondition, 
it  is  always  enabled.  If  a  state  component  or  variable  is  not  mentioned  in  the  effect  clause,  it  is 
left  unchanged  by  the  action.  The  partition  consists  of  a  class  for  each  i  €  X  that  contains  all  the 
output  actions  of  p,-. 

Essentially,  the  algorithm  proceeds  in  two  stages.  After  receiving  a  UserTry;  input,  p ,  sets  its 
contro1  v»  iable  to  1  and  enters  stage  one.  In  stage  one,  it  continually  reads  k  and  checks  to  see  if 
controlf/:]  is  0.  If  it  finds  a  0  in  control[fc],  it  sets  k  to  its  own  index  i.  If  it  reads  k  and  finds  it  equal 
to  i,  pi  proceeds  to  stage  two  and  sets  its  control  variable  to  2.  In  stage  two,  p,-  performs  a  final 
check  by  examining  the  control  variables  of  all  the  other  processes.  If  any  of  these  control  variables 
are  found  to  be  2,  then  p,-  fails  and  returns  to  stage  one  (where  it  sets  its  control  variable  back  1). 
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•  UserTry, 

Eff:  s.stage;  =  try 

t  Try; 

Pre:  s'.stage;  S  {try,  failed} 

Eff:  v.controlfi]  =  1 

s.checked;  =  {•} 
s.  stage;  =  read 

f  Read; 

Pre:  /.stage,-  =  read 
Eff:  s.ki  =  v'.k 

if  s.ki  =  *  then 

s.stage,  =  control2 

else 

s.stage;  =  check 

f  Check};); 

Pre:  s'.stage;  =  check 
j  =  s'.ki 

Eff:  if  /.control}/]  =  0  then 

s.stage;  =  set 

else 

s.  stage,-  =  read 

f  Set; 

Pre:  /.stage,-  =  set 
Eff:  v.k  =  i 

s.stage;  =  read 

f  Conlrol2; 

Pre:  s'. stage,-  =  control2 

Eff:  «.control[i]  =  2 

s.  stage,-  =  final.check 

t  FinalCheck(y); 

Pre:  s'. stage,-  =  final.check 

j  (f.  s'. checked; 

Eff:  if  /.control};]  =  2  then 

s. stage,-  =  failed 

else 

s. checked,-  =  s'.checked,-  U  {;} 

•  Crit; 

Pre:  s',  stage,-  =  final.check 

|s'.checked,|  =  n 
Eff:  s. stage,-  =  crit 

•  UserExit; 

Eff:  s.stage,-  =  exit 
s. checked,  =  {*} 

f  Reset; 

Pre:  s'. stage,  =  exit 
Eff:  ti.control[i]  =  0 

s.stage,-  =  done 

•  Rem; 

Pre:  s'.stage,-  =  done 
Eff:  s.stage,-  =  remainder 

Figure  1:  Transition  Relation  for  p,-  in  Dijkstra’s  Algorithm 
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Otherwise,  p,-  finds  all  the  control  variables  to  be  less  than  2  and  issuer  a  Crit,-  action,  allowing  u,- 
to  proceed  to  the  critical  section.  After  «,-  leaves  the  critical  section  (and  issues  a  UserExit,-  action), 
Pi  resets  its  control  variable  to  0  and  issues  a  Rem,-  action. 

We  associate  with  each  pi  an  access  partition  ip'  as  follows:  For  each  j  £  X)  ip'T{control[j]j 
contains  the  labels  Check(j'),-  and  FinalCheck(j),-.  Also,  ip'w(control[i ])  contains  the  labels  Try,-, 
Control2,-,  and  Reset,-.  And  for  each  j  ^  i,  ip'w(control[j ])  is  empty.  Finally,  ipl(k)  contains  Read,- 
and  ip'w(k)  contains  Set,-.  The  following  result  follows  immediately  from  inspection  of  the  code. 

Lemma  14:  For  all  t  £  T,  automaton  p,-  is  a  single- variable  read- write  automat -*n  under  ip'. 

We  let  system  S  =  U(IIj<,-<np,-,  {&,  control[i],i  £  X})  be  the  composition  of  the  processes  of 
Dijkstra’s  algorithm,  closed  out  on  k  and  the  control  variables.  Furthermore,  we  hide  all  shared 
memory  actions  of  S  so  that  the  external  signatures  of  M  and  S  are  the  same.  One  may  note  that 
all  the  p^s  in  system  S  can  read  and  write  shared  variable  k,  whereas  the  variable  control[i]  may 
be  written  only  by  p,-  and  read  by  the  other  pj's.  That  is,  each  contro^i ]  is  owned  by  p,-,.  while  k  is 
a  multi-writer  variable. 

We  wish  to  show  that  system  S  solves  schedule  module  M.  The  proof  has  three  parts.  First,  we 
show  that  S  preserves  well-formedness  in  all  executions,  Condition  (1)  of  module  M.  In  Section  4.3, 
we  give  the  safety  proof,  Condition  (2a).  Finally,  we  present  the  progress  proof,  Condition  (2b),  in 
Section  4.4. 

If  i  is  a  process  index  and  s  is  a  state  of  system  S,  we  say  that  process  p,-  is  a  contender  in  state 
s,  written  contendeifi,  s),  iff  s.stage,-  £  {read,  check,  set,  control2,  final-check,  failed}. 

Lemma  15:  Let  a  be  an  execution  of  system  S  with  behavior  (3.  Then  system  S  preserves  well- 
formedness  in  (3 . 

Proof:  By  induction  on  the  length  of  a.  For  the  base  case,  if  a  contains  no  actions,  then  it  is 
well-formed.  Let  a  =  a' sir,  where  beh(a')  is  well-formed  and  r  is  an  output  action  of  S.  There  are 
two  cases. 

•  If  7r  is  a  Crit,-  action,  then  by  the  preconditions  of  that  action  it  must  be  that  p,-  is  a  contender 
in  state  s.  Therefore,  the  last  action  in  beh(a')\i  must  be  UserTry,-,  for  any  other  action  would 
leave  p,-  in  a  non-contender  state. 

•  If  7r  is  a  Rem,-  action,  then  by  the  preconditions  of  that  action  it  must  be  that  stage,-  =  done 
in  state  s.  Therefore,  the  last  action  in  (3'\i  must  be  Reset,-,  for  any  other  action  would  leave 
Pi  in  a  state  with  stage,-  done.  Since  Reset,-  is  only  enabled  when  stage,-  =  exit,  the  last 
action  in  beh(f3')\i  must  be  UserExit,-,  for  any  other  action  would  leave  p,-  in  a  state  with 
stage,-  yi  exit. 

In  both  cases,  (3  is  well-formed.  ■ 

The  following  lemma  will  be  used  in  the  safety  proof  to  rule  out  the  occurrence  of  UserTry  and 
UserExit  actions  from  certain  states. 

Lemma  10:  Let  a  be  an  execution  of  system  S  with  behavior  /?.  If  (3  is  well-formed,  then  for 
all  states  s  in  a,  if  s  is  immediately  followed  by  a  UserTry,  (UserExit,-)  action,  then  s.stage,-  is 
remainder  (crit). 

Proof:  If  s  is  followed  by  UserTry,-,  then  by  definition  of  well-formedness,  the  preceding  action 
in  /?j i  is  a  Rem,-  action,  and  a  Rem,-  action  leaves  stage,-  =  remainder.  Furthermore,  no  output 
actions  ofp,-  are  enabled  while  stage,-  =  remainder.  If  s  is  followed  by  UserExit,-,  then  by  definition 
of  well-formedness,  the  preceding-  action  in  (3\i  is  a  Crit,-  action,  and  a  Crit,-  action  leaves  stage,-  = 
crit.  Furthermore,  no  output  actions  of  p,-  are  enabled  while  stage,-  =  crit.  ■ 
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4.3  Safety  Proof 

Let  5  be  a  state  of  system  S.  To  denote  the  set  of  processes  in  (or  about  to  enter)  their  critical 
sections,  we  define  the  set  ready(s )  =  {i  :  (s.stage;  =  crit)  V  (|s.checked;|  =  n)}.  The  proof  is 
based  on  a  set  of  invariants,  proved  in  the  following  Lemma.6  Using  Spectrum,  this  Lemma  was 
checked  mechanically  for  all  states  of  random  executions  of  the  algorithm. 

Lemma  17:  Let  a  be  a  well-formed  execution  of  system  S.  In  states  s  of  a,  for  all  processes  p; 
and  pjy  the  following  facts  hold: 

1.  s.control[z]  =  2  iff  s.stage;  €  {final-check,  failed,  crit,  exit}. 

2.  If  s. checked,-  {z}  then  s.stage;  £  {final-check,  failed,  crit}. 

3.  If  i  ^  j,  then  i  £  s.checkedj  =$■  j  £  s.checked;. 

4.  If  i  £  ready(s)  then  s.checked,-  =  {1,2,  ...n}. 

5.  If  s.stage,-  £  {control2,  final-check,  failed,  crit,  exit,  done},  then  s.fc;  =  z. 

Proof:  In  the  initial  state  of  S,  Vz  £  1,  controlfz]  =  0,  checked,-  =  {z},  and  stage,-  =  remainder. 
Therefore,  all  the  facts  hold  in  the  initial  state.  Let  a  =  a'zrs,  and  assume  that  the  facts  hold  in 
all  states  of  a',  and  specifically  in  the  last  state  s'  of  a'.  We  consider  each  fact  in  turn,  showing 
that  it  must  hold  in  state  s  as  well. 

1:  If  s'.control[z]  =  2,  then  by  the  induction  hypothesis  s'.stage;  £  S  =  {final-check,  failed, 
crit,  exit}.  Therefore,  zr  must  be  either  Try,-,  FinalCheck(j),-,  Crit,-,  UserExit,-,  or  Reset,-. 
(Lemma  16  rules  out  UserTry;.)  The  actions  FinalCheck,  Crit,-,  and  UserExit,-  do  not  change 
the  value  of  control[z]  and  result  in  s.stage;  £  S.  The  actions  Try,-  and  Reset;  both  cause 
s.control[z]  ^  2,  but  also  result  in  s.stage;  £  S.  Therefore,  the  property  is  preserved  if 
s'.control[i]  =  2. 

If  s'.control[i]  ^  2,  then  by  the  induction  hypothesis  s'.stage;  ^  S.  Therefore,  7r  mast  je 
either  UserTry,-,  Try,-,  Read,-,  Check(y),-,  Set,-,  Control2,-,  or  Rem,-.  (By  Lemma  16,  UserExit; 
is  ruled  out.)  Actions  UserTry,-,  Read;,  Check(j),-,  Set;,  and  Rem,-  do  not  change  the  value 
of  controlfi]  and  result  in  s.stage,-  £  S.  Furthermore,  the  action  Try,-  sets  control[i]  =  1  and 
results  in  s.stage;  <f.  S.  Finally,  the  action  Control2;  sets  control[i]  =  2,  but  also  results  in 
s.stage,-  £  S.  Therefore,  the  property  is  preserved  if  s'.controlfi]  ^  2. 

2:  If  s'.checked;  =  {i},  then  the  only  possibility  for  it  which  could  cause  s'.checked;  ^  {z}  is 
FinalCheck(y),-.  This  action  is  only  enabled  if  s'.stage[z]  =  final-check.  The  FinalCheck(j); 
either  does  not  change  stage,-  or  sets  s.stage,-  =  failed.  Therefore,  the  property  is  preserved. 

If  s'.checked;  ^  {z},  then  by  the  induction  hypothesis,  s'.stage;  £  {final-check,  failed,  crit}. 
Therefore,  the  only  possibilities  for  n  which  could  cause  s.stage,-  ^  {final-check,  failed,  crit} 
are  Try,-  and  UserExit,-.  (The  action  UserTry;  is  ruled  out  by  Lemma  16.)  However,  in  both 
cases,  s.checked;  —  {z*},  so  the  property  is  preserved. 

3:  The  proof  is  by  contradiction.  Suppose  3z  ^  j  such  that  z  £  s.checked^  and  j  £  s.checked,-. 
Without  loss  of  generality,  suppose  that  z  £  s'.checkedj,  and  let  zr  be  the  action  that  adds  j  to 
checked,-.  (By  the  induction  hypothesis,  we  know  that  j  £  s'.checked,-.)  The  only  possibility 

8Although  the  last  invariant  of  Lemma  17  is  used  only  in  the  liveness  proof,  we  present  it  here  because  of  its 
similarity  to  the  others. 
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for  7T  is  FinalCheck(j),-.  By  the  transit  relation,  i r  can  only  add  j  to  checked;  if  5'. control [j] 
^  2.  However,  by  the  induction  hypo;  tesis  (Fact  2),  we  know  that  s'. stagey  G  {final-check, 
failed,  crit},  since  s'.checkedj  ^  {j}.  Therefore,  by  Fact  1,  we  know  that  s'.controlfj]  =  2,  a 
contradiction. 

4:  Recall,  from  the  definition,  that  i  G  ready(s)  iff  s.stage;  =  crit  V  |s. checked, -|  =  n.  By  a 
pigeonhole  argument,  the  fact  clearly  holds  when  |s.checked;|  =  n.  If  s'.stage;  ^  crit,  then 
the  only  possibility  for  it  to  make  s.stage;  =  crit  is  the  Crit;  action.  That  action  has  as  a 
precondition  that  |checked;|  =  n,  and  does  not  change  the  value  of  checked;.  Therefore,  the 
property  is  preserved.  If  s'.stage;  =  crit,  then  the  only  possibility  for  7r  to  make  |s.checked;|  jt. 
n  is  UserExit;,  but  this  also  results  in  stage;  =  exit. 

5:  If  s'.stage;  G  {control2,  final-check,  failed,  crit,  exit,  done},  then  by  the  inductive  hypothesis, 
s'.ki  =  i.  Furthermore,  the  only  action  which  can  change  fc;  is  a  Read;  action,  which  is  only 
enabled  if  stage;  =  read,  so  s.k,  =  s'.ki  =  i-  If  s'.stage;  £  {control2,  final-check,  failed,  crit, 
exit,  done},  then  the  only  possible  action  for  k  which  could  cause  s.stage;  to  be  in  that  set 
is  a  Read;  action.  (Lemma  16  rules  out  UserExit;.)  However,  the  Read;  action  can  only  set 
s.stage;  =  control2  if  s.fc;  =  i.  Thus,  the  property  is  preserved. 

All  five  facts  hold  in  state  s.  ■ 

We  can  now  show  that  no  two  process*:0  ‘\ay  be  in  (or  about  to  enter)  their  critical  sections. 

Theorem  18:  If  s  is  a  state  of  system  lready(s)|  <  1. 

Proof:  By  contradiction.  Suppose  |ready(s)|  >  1.  Then  by  Fact  4  of  Lemma  17,  there 
must  exist  two  processes  p;  and  pj  such  that  s.checked;  =  s.checkedj  =  {1,2,  ...n}.  However,  this 
contradicts  Fact  3  of  Lemma  17.  ■ 

It  follows  that  the  algorithm  satisfies  mutual  exclusion. 

Corollary  19:  Let  a  be  a  well-formed  execution  of  system  S.  Then  ii,j  G  I,  if  Crit;  and  Critj 
occur  in  a  (in  that  order),  then  UserExit;  occurs  between  them. 

Proof:  By  well-formedness  and  inspection  of  the  code  for  system  5,  if  a  Crit;  action  occurs  in 
a  then  stage;  =  crit  in  all  states  up  until  the  next  UserExit;  action.  Suppose  (for  contradiction) 
that  there  exist  two  processes  p;  and  pj  such  that  Crit;  and  Critj  occur  in  a  (in  that  order)  and  no 
UserExit;  occurs  between  them.  Then  after  Critj  occurs,  stage;  =  crit  and  stagej  =  crit.  However, 
by  Theorem  18  and  the  definition  of  ready,  this  is  impossible.  ■ 

4.4  Progress  Proof 

In  this  section,  we  show  that  Dijkstra’s  algorithm  makes  progress:  if  a  process  is  attempting  to 
enter  the  critical  section,  then  eventually  it  or  some  other  process  will  enter  the  critical  section. 
We  define  a  “no-progress  execution”  of  system  S  and  then  show  that  no  such  executions  exist.  The 
proof  is  by  contradiction:  We  define  a  well-founded  variant  function,  or  progress  metric.  Then  we 
show  that  in  no-progress  executions  the  function  is  nonincreasing  and  must  eventually  decrease. 
Since  no  infinite-length  decreasing  chains  are  possible,  this  shows  that  no-progress  executions  do 
not  exist.  The  notion  of  fairness,  which  we  inherit  “for  free”  from  the  original  I/O  automaton 
model,  is  used  to  show  that  the  variant  function  eventually  decreases. 

Let  7  =  oc0  be  a  fair  well-formed  user-live  execution  of  system  S.  Furthermore,  let  none  of  the 
following  actions  occur  in  0:  UserTry,  Crit,  UserExit,  Rem.  If  0  begins  with  a  state  in  which  some 
process  has  stage  7^  remainder,  then  0  is  said  to  be  a  no-progress  execution  suffix  and  7  is  said  to 
be  a  no-progress  execution. 
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Lemma  20:  Let  /?  be  a  no-progress  execution  suffix,  and  let  s  be  a  state  in  (5.  Then  Vi  €  X, 
s. stage;  ^  {crit,  exit,  done}. 

Pro  _  1  ^mediate  from  the  definitions  of  no-progress  execution  suffix,  fairness,  and  Pi-  ■ 

Before  defining  the  variant  function,  we  identify  an  important  predicate  on  system  states.  If  s 
is  a  state  of  5,  we  say  that  s  is  consistent ,  denoted  consisteni(s),  iff  for  alii  €  X,  contender(i,  s) 
=£  s.k{  =  s.k. 

We  now  define  the  variant  function.  Given  state  s  of  system  S,  we  define 

f(s)  =  (A,  B,  C,  D,  E,  F,  <?,  H,  J,  J ,  if), 

where  each  tuple  component  has  the  nonnegative  integer  value  defined  as  follows: 

A  =  |{i :  s.stage;  =  try}|. 

B  —  |{i :  s.stage,-  =  read}|  if  -icontender(s.A:,s), 

0  otherwise. 

C  =  |{i  :  s.stage;  =  check  A  -icontender(.s.A:;,s)}|. 

D  =  0  if  contender(s.fc,s),  1  otherwise. 

E  =  |{i  :  s.stage,-  =  set}|. 

F  =  |{i  :  s.stage;  =  control2  A  i  ^  s.k} |. 

G  =  |{i  :  s.stage,-  =  final.check  A  i  ^  s.k} |. 

H  =  |{i :  contender(i,s)  A  A:,-  ^  s.A:}|. 

/  =  S,(n  -  |checked,-|),  for  all  i  ^  s.A:  such  that 
s. stage,-  =  finaLcheck. 

J  =  |{i  :  s.stage,-  =  failed  A  i  ^  s.fc}|. 

/f  =  n  if  (->consisteut(s)  V  s.stage,^  ^  finaLcheck), 
n  -  |checked,.fc|  otherwise. 

We  define  a  lexicographic  total  order  on  the  elements  in  the  range  of  /.  We  will  show  that  / 
is  nonincreasing  and  will  eventually  decrease  in  a  no-progress  execution  suffix,  but  first  we  explain 
the  components  of  /.  The  components  A ,  E,  F,  G,  and  J  simply  count  the  number  of  processes  in 
a  certain  stage  (in  some  cases  ignoring  the  process  whose  index  is  the  value  of  the  shared  variable 
k).  These  components  measure  progress  of  the  contenders  through  the  different  stages  of  the 
algorithm.  Components  B  and  C  serve  a  similar  purpose  for  the  “read”  and  “check”  stages,  but 
are  more  complicated  because  contenders  may  cycle  through  these  two  stages  while  they  wait  for 
some  other  process  to  “get  out  of  the  way.”  Component  B's  purpose  is  to  count  the  number  of 
processes  in  the  “read”  stage;  however,  when  the  shared  variable  k  is  the  index  of  a  contender, 
B  =  0.  In  this  way,  the  value  of  B  does  not  increase  when  a  contender  “backs  off”  to  read  k  again. 
Component  C  counts  the  number  of  processes  in  the  “check”  stage  whose  local  k  variables  contain 
indices  of  non-contenders. 

Component  D  becomes  0  when  the  shared  variable  k  is  set  to  the  index  of  a  contender,  and 
remains  1  otherwise.  Components  I  and  I(  both  count  down  the  number  of  indices  that  are  missing 
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from  the  checked  sets  of  processes  whose  stage  is  “final-check.”  Component  I  hold  the  sum  of  this 
count  for  all  the  contenders  whose  indices  are  not  equal  to  the  shared  variable  k.  Component  K 
holds  this  count  for  the  (at  most  one)  contender  whose  index  is  equal  to  the  shared  variable  k,  but 
only  starts  counting  down  after  all  other  contenders  are  “out  of  the  way,”  meaning  that  their  local 
s  are  equal  to  the  shared  k. 

In  studying  the  variant  function,  two  important  progress  “landmarks”  should  be  noted.  The 
first  is  when  component  D  reaches  0,  after  which  point  the  value  of  k  is  always  the  index  of  a 
contender.  After  D  reaches  0,  the  second  landmark  is  when  component  H  reaches  0,  meaning 
that  all  later  states  are  consistent.  After  this  point,  all  processes  other  than  p*  cannot  escape  the 
Read-Check  cycle,  so  nothing  stands  in  p*’s  way. 

We  now  show  that  the  value  of  the  variant  function  /  is  nonincreasing  in  no-progress  execution 
suffixes,  and  that  only  certain  steps  leave  /  unchanged.  Using  Spectrum,  this  lemma  (and  earlier 
incorrect  versions  of  it)  was  checked  for  random  algorithm  executions.  That  is,  for  each  step  it  was 
mechanically  verified  that  either  (1)  progress  was  being  made  (see  Lemma  20),  or  (2)  the  variant 
function  decreased,  or  (3)  the  variant  function  was  unchanged  and  one  of  the  exceptions  held. 

Lemma  21:  Consider  any  state  s'  in  /?,  a  no-progress  execution  suffix.  If  action  tc  of  process  p; 
occurs  from  state  s'  producing  state  s,  then  the  following  conditions  hold: 

1.  f(s')  >  f(s ),  and 

2.  either  /(s')  >  /(s)  or  one  of  the  following  hold: 

(a)  7r  is  a  Read  action  and  s'.ki  =  s'.k,  a  contender,  or 

(b)  7r  is  a  Check  action  and  s'.ki  is  a  contender,  or 

(c)  7r  is  a  Try  action,  i  =  s'.k,  and  s'.stage;  =  failed,  or 

(d)  7r  is  a  Ccntrol2  action  and  i  =  s'.k,  or 

(e)  7r  is  a  FinalCheck  action,  i  =  s'.k,  and 
-iconsistent(s'). 

Condition  (1)  says  that  the  variant  function  is  nonincreasing.  Condition  (2)  says  that  every  action 
must  decrease  the  variant  function,  except  for  a  few  special  cases.  Exceptions  (2a)  and  (2b)  handle 
the  case  of  a  process  cycling  through  the  “read”  and  “check”  stages,  waiting  for  some  other  process 
to  get  out  of  the  way.  Note  the  relationship  between  items  (2a)  and  (2b)  and  the  variant  function 
components  B  and  C,  respectively.  A  process  does  not  make  progress  when  it  reads  the  same  value 
of  the  shared  variable  k  that  it  read  the  previous  time.  Similarly,  a  process  does  not  make  progress 
if  it  discovers  that  the  control  variable  corresponding  to  its  local  k  is  nonzero.  Exceptions  (2c), 
(2d),  and  (2e)  pertain  only  to  the  contender  whose  index  is  the  value  of  the  shared  variable  k. 
Process  pk  may  “back  off”  several  times  before  it  finally  enters  the  critical  section,  and  the  variant 
function  is  carefully  constructed  not  to  change  when  pk  backs  off.  These  last  three  exceptions  are 
the  necessary  result. 

Proof:  By  case  analysis.  For  each  possible  action,  we  note  the  changes  in  the  components  of 
the  variant  function  /.  (We  will  use  A'  and  A  to  denote  the  first  components  of  f(s')  and  f(s), 
respectively.  Similarly  for  B'  and  B,  etc.)  Each  case  may  be  verified  by  Lemma  20  and  inspection 
of  the  preconditions  and  effects  of  the  action  under  consideration. 

•  If  7r  =  ( v ',  Try,-,  v ),  there  are  three  cases: 

(1)  If  s'.stage,-  =  try,  then  A'  >  A,  decreasing  /. 
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(2)  If  s'.stage;  =  failed  and  i  ^  s'.k,  then  J'  >  J,  and  no  components  increase.  (Component 
B  cannot  increase  because  Fact  (5)  from  Lemma  17  tells  us  that  if  stage;  =  failed,  then  &;  =  i, 
a  contender  by  definition.)  Therefore,  /  is  decreased. 

(3)  If  s'.stage;  =  failed  and  i  =  s'.k ,  then  f(s')  =  /(s),  satisfying  Condition  1  and  exception 
2c. 

•  If  7r  =  ( v ',  Read;,  v ),  there  are  three  cases: 

(1)  If  s'.k  is  not  a  contender,  then  B'  >  B  and  A  is  unchanged,  so  /  decreases. 

(2)  If  s'.ki  s'.k,  then  H'  >  H  and  no  higher  order  components  are  increased,  so  /  decreases. 

(3)  If  s'.ki  —  s'.k,  a  contender,  then  f(s')  =  f(s),  satisfying  Condition  1  and  exception  2a. 

•  If  7r  =  (t/,  Check(j);,  v),  there  are  two  cases: 

(1)  If  s'.ki  is  a  contender,  then  /(s')  =  /(s),  satisfying  Condition  1  and  exception  2b. 

(2)  Otherwise,  C'  >  C,  and  A  and  B  are  unchanged,  so  /  is  decreased. 

•  If  7r  =  ( v ',  Set,  v ),  then  B  =  0,  D  =  0,  E'  >  E,  and  A  and  C  are  unchanged.  Therefore  / 
decreases. 

•  If  7r  =  ( v ',  Control2;,  v ),  there  are  two  cases: 

(1)  If  i  =  s'.k  then  /(s')  =  /(s),  satisfying  Condition  1  and  exception  2d. 

(2)  Otherwise,  F'  >  F  and  no  higher  ""-der  components  are  changed,  so  /  decreases. 

•  If  7r  =  (v',  FinalCheck(j);,  v),  there  are  three  cases: 

(1)  If  i  ^  s'.k,  then  /'  >  /  and  no  higher  order  components  are  changed,  so  /  decreases. 

(2)  If  i  =  s'.k  and  -iconsistent(s'),  then  /(s')  =  /(s),  so  Condition  1  and  exception  2d  are 
satisfied. 

(3)  If  i  =  s'.k  and  consistent(s'),  then  K  is  the  only  component  that  may  change.  Suppose, 
for  contradiction,  that  K  does  not  decrease.  By  the  effects  of  FinalCheck  and  the  definition 
of  K,  the  only  way  for  this  to  happen  is  for  s'.control[j]  =  2.  If  s'.control[jf]  =  2,  then  Fact 
1  of  Lemma  17  tells  us  that  s'.stage[j]  €  {finaLcheck,  failed,  crit,  exit}.  Therefore,  by  Fact 
5  of  the  same  Lemma,  s'.kj  =  j.  Since  s'  is  consistent,  s'.kj  =  s'.k,  and  we  have  stated  that 
s'.k  =  i.  So,  by  transitivity,  j  =  i.  By  the  preconditions  on  FinalCheck,  j  £  s'. checked;. 
But  i  €  s'. checked;,  since  i  €  checked;  initially  and  no  action  may  remove  it  from  that  set. 
Therefore  j  £i,  a  contradiction. 

In  each  case,  the  Lemma  holds.  The  set  of  cases  is  complete  by  Lemma  20  and  the  definition  of  a 
no-progress  execution.  ■ 

Wo  have  just  shown  that  the  value  of  the  variant  function  /  never  increases  in  a  no-progress 
execution  suffix,  and  that  only  certain  steps  leave  its  value  unchanged.  Now  we  will  show  that  a  fair 
execution  cannot  proceed  using  only  those  certain  steps,  so  the  function  must  eventually  dec-ease. 

Corollary  22:  Let  a  be  a  no-progress  execution  suffix.  Then  /  must  eventually  decrease  in  a. 

Proof:  Suppose  that  /  is  fixed  in  a',  a  suffix  of  a.  Then,  by  Lemma  21  for  all  slates  s'  of  a', 
if  t.  occurs  from  s',  then  one  of  the  following  hold: 

•  7r  is  a  Read  action  and  s'.k{  =  s'.k,  a  contender,  or 

•  7r  is  a  Check  action  and  s'.ki  is  a  contender,  or 

•  7r  is  a  Try  action,  i  =  s'.k,  and  s'.stage;  =  failed,  or 
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•  7T  is  a  Control2  action  and  i  =  s'.k ,  and 

•  7r  is  a  FinalCheck  action,  i  =  s'.k,  and  -iconsistent(s'). 

Since  no  action  in  a'  is  a  Set  action,  the  shared  variable  k  is  fixed  in  a'.  Fairness  tells  us  that  all 
contenders  must  continue  taking  steps.  (Inspection  of  the  code  will  reveal  that  a  contender  always 
has  some  step  enabled.)  Therefore,  by  the  four  conditions  above,  all  contenders  other  than  pk 
must  have  stage  6  {read,  check);  otherwise  their  steps  would  decrease  the  value  of  /,  contradicting 
our  assumption  that  /  is  fixed.  Therefore,  by  the  same  fairness  argument,  a  Read  action  must 
eventually  occur  for  each  of  these  contenders,  after  which  point  its  local  value  of  k  matches  the 
shared  k. 

Let  a"  be  the  suffix  of  a'  after  which  all  contenders  other  than  pjt  have  their  local  k* s  equal 
to  the  shared  k.  Now,  consider  pk,  which  must  continue  to  take  steps  in  a",  and  let  s"  be  a  state 
in  a"  from  which  pk  takes  a  step.  If  pk  takes  a  FinalCheck  step,  then  by  Fact  5  of  Lemma  17, 
s".kk  =  s".k.  However,  this  implies  that  s"  is  consistent.  Therefore,  the  conditions  above  imply 
that  no  FinalCheck  actions  can  occur.  If  pk  takes  a  Control2  step,  then  a  FinalCheck  action  will 
become  enabled  and  remain  enabled  until  it  occurs,  so  fairness  tells  us  that  a  FinalCheck  action 
will  eventually  occur,  but  we  have  just  ruled  this  out.  The  only  remaining  actions  for  pk  are  Read, 
Check,  and  Try.  If  pk  takes  a  Read  step,  then  it  will  observe  that  the  shared  k  contains  its  own 
index  and  proceed  to  stage  =  control2,  meaning  that  it  must  eventually  take  a  Control2  step,  which 
we  have  already  ruled  out.  If  pk  takes  a  Check  step,  then  since  (by  statement  2  above)  s".kk  is 
a  contender,  it  will  proceed  to  stage  =  read,  meaning  that  it  must  eventually  take  a  Read  step, 
which  we  have  just  ruled  out.  Finally,  if  pk  takes  a  Try  step,  it  will  also  proceed  to  stage  =  read. 
Therefore,  if  pk  continues  to  take  steps,  it  eventually  will  decrease  the  value  of  /,  giving  us  our 
contradiction.  ■ 

Our  main  liveness  result  follows  immediately. 

Theorem  23:  The  set  of  no-progress  executions  for  Dijkstra’s  algorithm  is  empty. 

Proof:  By  Lemma  21,  we  know  that  the  value  of  the  variant  function  /  is  nonincreasing  in  a 
no-progress  execution  suffix.  Furthermore,  by  Lemma  22,  the  value  of  /  never  reaches  a  fixed  point. 
Therefore,  since  /  cannot  infinitely  decrease,  the  theorem  holds.  ■ 

Finally,  we  show  that  the  above  theorem  implies  that  Dijkstra’s  algorithm  satisfies  the  required 
progress  property. 

Corollary  24:  Let  a  be  a  fair  well-formed  user-live  execution  of  system  B.  Then  either  Vi,  a\i 
ends  with  Rem,-,  or  3i  such  that  a\i  is  infinite. 

Proof:  By  contradiction.  Suppose  that  a  is  finite  and  that  there  exists  some  /  el  such  that  a|/ 
does  not  end  with  Rem,-.  Then  there  exists  a  suffix  of  a  in  which  pi  has  stage  remainder  and  a\i 
is  empty  for  all  i.  This  is  a  no-progress  execution  suffix,  by  definition.  Therefore  a  is  a  no-progress 
execution,  which  is  a  contradiction  of  Theorem  23.  ■ 

5  Conclusion 

We  have  extended  the  I/O  automaton  model  to  allow  modelling  of  shared  memory  systems,  as 
well  as  systems  that  include  both  shared  memory  and  shared  action  communication.  The  extended 
model  was  shown  to  support  all  types  of  atomic  accesses  to  shared  memory,  from  the  very  restrictive 
single-variable  reads  and  writes  to  operations  on  arbitrary  abstract  data  types.  By  building  our 
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shared  memory  model  on  top  of  I/O  automata,  we  could  take  advantage  of  the  fairness  definitions 
and  compositionality  properties  already  present  in  that  model.  This  resulted  in  a  unified  model 
with  relatively  few  new  concepts.  An  example  algorithm,  Dijkstra’s  classical  shared  memory  mutual 
exclusion  algorithm,  was  presented  in  this  model  and  its  safety  and  progress  properties  were  shown 
using  standard  assertional  r  ,'d  variant  function  techniques. 
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